- Pharo-dev - lists.pharo.org

Re: [Pharo-project] [Issue Tracker] [Action Needed] Show Stoppers 2.0

by StÃ©phane Ducasse

thanks This is the best way to get the system better. Stef On Jan 29, 2013, at 3:16 PM, Denis Kudriashov wrote: > I uploaded fix to PharoInbox > With it image not hangs and starts correctly. > But existed loaded fonts are not valid in moved images because of saved absolute file path > > > 2013/1/29 Marcus Denker <marcus.denker(a)inria.fr> > > On Jan 29, 2013, at 10:25 AM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > >> Hello. >> >> Just want to notice issue http://code.google.com/p/pharo/issues/detail?id=6885 >> It about hanging image when it can not load fonts. >> >> If it will not fixed in 2.0 release I think many non latin users will have many bad words about pharo when they can't move their images on different computers. Images with loaded specific fonts can't start on computers which not have it (or placed in different directories). >> >> I was wait somebody with fonts knowledge look at this issue. I'm sure it is not difficult problem. Now when nobody solve it I will try fix it by myself. > > There are two solutions: > > 1) decide which issues are needed to be fixed and fixable, fix them and release > 2) Do not decide, claim that "only a perfect release is a good release", and *never* release. > > Marcus >

Jan. 29, 2013

Re: [Pharo-project] Monticello class V.S. classSide

by StÃ©phane Ducasse

> On Tue, Jan 29, 2013 at 5:49 PM, StÃ©phane Ducasse > <stephane.ducasse(a)inria.fr> wrote: >> What do you mean? > > the screenshot shows a line ending with 'classSide' and a line ending > with 'class'. We don't understand why there are 2 different suffixes Ok I saw after. me neither :) This is strange. Can you open a bug entry so we do not forget. Stef

Jan. 29, 2013

Re: [Pharo-project] [update 2.0] #20496

by StÃ©phane Ducasse

> Stef, do you see this entry!! yes and we spent a lot of time with it. Trying a lot of different ways to understand it and fix it. Now we are sure that this is 7240 that introduced it. Don't be worry Camille: the classBuilder is an really really ugly part of the system that we should ***throw away*** but it will take time. > https://code.google.com/p/pharo/issues/detail?id=7352 > > if you continue developing you will seriously screw up the image... > > we need discipline on that, if a HorribleErrorBlockingEverything appears the world stops > and all forces focus on thatâ¦. I was not aware of that protocol. >> From santiago :) >> >> 20496 >> ----- >> >> Issue 7349: rootApplication does not exist in Pharo. Thanks Vanessa Pena and Pablo Estefo. >> http://code.google.com/p/pharo/issues/detail?id=7349 >> >> Issue 7349: rootApplication does not exist in Pharo. Thanks Vanessa Pena and Pablo Estefo. >> http://code.google.com/p/pharo/issues/detail?id=7349 >> >> Issue 7356: New comment in MessageTally> Thanks Alexandre and Milton. >> http://code.google.com/p/pharo/issues/detail?id=7356. >> >> Issue 7328: diffmorph does not shows the middle separator. Thanks Sean De Nigris. >> http://code.google.com/p/pharo/issues/detail?id=7328 >> Diff information: >> http://ss3.gemstone.com/ss/Pharo20/Tools-StephaneDucasse.1020.diff >> http://ss3.gemstone.com/ss/Pharo20/Refactoring-Tests-Core-StephaneDucasse.6… >> http://ss3.gemstone.com/ss/Pharo20/Polymorph-Widgets-StephaneDucasse.761.di… >> >> > >

Jan. 29, 2013

Re: [Pharo-project] Error: cannot remove non empty category [pharo issue 7284]

by StÃ©phane Ducasse

> Hello, > > We are working on a pharo issue 7284: "Error: cannot remove non empty category". > > A simple script to reproduce this issue is the following. > Gofer new > squeaksource: 'Roassal'; > package: 'ConfigurationOfRoassal'; > load. > ((Smalltalk at: #ConfigurationOfRoassal) project version: '1.200') load. > ((Smalltalk at: #ConfigurationOfRoassal) project version: '1.269') load. > > > The problem is in the method MCOrganizationDefinition>>unload, it uses the removeCategory: method and this method don't delete the classes inside the category and raise an error: > MCOrganizationDefinition>>unload > categories do: [ :c | SystemOrganization removeCategory:c ]. > A possible solution for this could be use the removeSystemCategory: instead, since it delete the classes inside and then the category. > MCOrganizationDefinition>>unload > categories do: [ :c | SystemOrganization removeSystemCategory: c ]. > > Perhaps, we are not sure about our solution. We want to have your opinion about it :) We discussed a lot about it. and I would love to get some other opinions on it. > It's removing the classes inside the category is what we really want to do? There is a reason for not deleting the classes inside? > > Regards, > Juan Pablo & Alejandro

Jan. 29, 2013

Re: [Pharo-project] NativeBoostFFI out parameters passing pointers back and forth is confusing...

by Stefan Marr

Hi Igor: On 29 Jan 2013, at 11:26, Igor Stasenko wrote: >> | repo repoPath cb branches headHandle | >> repo := NBExternalHandle new. >> repoPath := NBExternalAddress fromString: '/Users/smarr/tmp/filetree'. > > why not just pass the string? I had the feeling (i.e., I had crashes, and was checking with GDB) that plain Smalltalk strings ala 'test' are not actually passed properly into the function. What is passed in is a reference to the begin of the string, but not a properly null terminated string. Do I miss something? Thanks Stefan -- Stefan Marr Software Languages Lab Vrije Universiteit Brussel Pleinlaan 2 / B-1050 Brussels / Belgium http://soft.vub.ac.be/~smarr Phone: +32 2 629 2974 Fax: +32 2 629 3525

Jan. 29, 2013

Re: [Pharo-project] Where to get the VM?

by StÃ©phane Ducasse

On Jan 29, 2013, at 7:38 PM, Camillo Bruni wrote: > Yes that would be the ideal case, but the limited space on our old brittle jenkins > made our system very fragile. > > We could only keep a couple of versions of each build. > Result? > We lost the stable builds, hence I started to backup files in the easiest way possible, > on a dumb file server. > > How could we have avoided the current mess? > Simply by moving early enough to the right infrastructure half a year ago would have saved > us many burnt brain cells. Yes I totally agree! > So I naturally get upset if all of a sudden everything has to work out of the blue. I understand and you pushed a lot. Now for 2.0 we should get to the next level. > We left the old jenkins in ruins and we are building the new one ad-hoc. There is no > going back as the old server is simply dead, besides our admins are clueless about the > crashes, taking random reboots as a good habit. > > So I expect that YOU take your time to look at the new setup yes but do not alex or a guys with two months of pharo to do it and during our great sprint some smart guys just not even got 1 months of pharo. > and understand it. Yes do you think that I'm doing nothing - just relaxing in chile :) Now I'm sick and I promote Pharo and I talk with people of govermental agencies during meetings in spanish to sell projects and give job to people :). Now we are not talking about me but the outside world. You know rmod not. > If I had to take a look at our budget I would do the same, of course with my amount > if complaint because I would not know your private systemâ¦ Our team budget is freely accessible to you. This is just that you never needed to look at it. Because your salary is not on our budget :). So you are safe :) Stef

Jan. 29, 2013

Re: [Pharo-project] Where to get the VM?

by Camillo Bruni

Yes that would be the ideal case, but the limited space on our old brittle jenkins made our system very fragile. We could only keep a couple of versions of each build. Result? We lost the stable builds, hence I started to backup files in the easiest way possible, on a dumb file server. How could we have avoided the current mess? Simply by moving early enough to the right infrastructure half a year ago would have saved us many burnt brain cells. So I naturally get upset if all of a sudden everything has to work out of the blue. We left the old jenkins in ruins and we are building the new one ad-hoc. There is no going back as the old server is simply dead, besides our admins are clueless about the crashes, taking random reboots as a good habit. So I expect that YOU take your time to look at the new setup and understand it. If I had to take a look at our budget I would do the same, of course with my amount if complaint because I would not know your private system...

Jan. 29, 2013

Re: [Pharo-project] I hate 'as yet unclassified'

by StÃ©phane Ducasse

Ok but in 3.0 We will kill that bad habit. We should investigate in an automatic categorizer. There was one I should have a look one of these days (since I do not know what to do :)). Stef > Code with "as yet unclassified" methods should be rejected by the monkey ! > > Ben > > On Jan 29, 2013, at 11:19 PM, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> >> On Jan 29, 2013, at 2:03 PM, Ben Coman wrote: >> >>> While on the topic, some of the category chooser dialogs are sorted so that the extensions are listed first - which I find annoying (in 1.4). In 2.0 can the standard categories be shown first ? >>> >>> Also, I still struggle to really be confident I am choosing the right categories. Perhaps down the track, a feature useful for newcomers might be a tooltip when hovering over items on the category list, or alternatively, hover showing a list of the ten most common methods appearing in that category. >> >> could be really neat :) >> >>> >>> cheers -ben >>> >>> StÃ©phane Ducasse wrote: >>>> Hi guys >>>> >>>> I spend my time recategorizing methods. >>>> I would like the change the intention of 'as yet unclassified' because this is a PLAGUE. >>>> It is like throwing papers on the floor. >>>> So we should have a different name to indicate that it should be fixed. >>>> >>>> >>>> Any ideas? >>>> >>>> 'you are a dirty programmer - change me' >>>> >>>> >>>> Stef >>>> >>>> >>>> >>>> >>>> >>> >>> >> >> >

Jan. 29, 2013

Re: [Pharo-project] Where to get the VM?

by StÃ©phane Ducasse

> you're over generalizing... PharoVM with NativeBoost + SSL + OSProcess + Freetype > will do the trick for most users, and that's what we aim for. We are talking about THE pharo VM and THE Pharo image. This is since august that I use the ***same*** pharo.14.zip and I'm happy. I know that there one and for the rest this is my problem. I use a configuration and get the stuff I need loaded. I do not ask the PUBLIC pharo building system to build it for me. If I need that I will create my own jenkins job in preview or experimental. Stef

Jan. 29, 2013

Re: [Pharo-project] Where to get the VM?

by StÃ©phane Ducasse

+ 1 >> Can the Jenkins job for the images add to the resulting zip >> a file named 'vm-used.txt' with a single line that points to the static download location of the vm used for that run ? > > > actually not a bad idea, this would be additional information to the download script and console output we have. > > The current problem is that all the VM's are unstable or have missing plugins, hence

Jan. 29, 2013