- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Fraction and isPowerOfTwo

by stepharo

Please please please you see we need pythondoc like things let us start by adding <expr: 2^-5 result: 1/32 > I know it is wrong because I did not get it :) Stef Le 27/8/16 Ã 03:04, Nicolai Hess a Ã©crit : > > > 2016-08-27 2:21 GMT+02:00 monty <monty2(a)programmer.net > <mailto:monty2@programmer.net>>: > > 2^-5 = (1/32) > > > Ah, ok. >

Aug. 27, 2016

SmalltalkHub over https

by Peter Uhnak

Hi, since Let's Encrypt offers free certs, is there any reason why smalltalkhub is not yet served over https? Maybe limitation of Zinc? I guess that's one benefit that we are such a small community that nobody nuked us yet... (e.g. every time you commit from free wifi (hotel, airport, caffee, ...) you give up your password). Peter

Aug. 27, 2016

Re: [Pharo-dev] broken GitFileTree/IceBerg on Windows because of ProcessWrapper

by stepharo

Once you have the file we can mirror it on our server. I always think about replication but this is not always the case. Stef Le 27/8/16 Ã 10:46, Peter Uhnak a Ã©crit : > Hi, > > GitFileTree / IceBerg is now broken, because ProcessWrapper (one of the deps on Windows) is downloading plugin from > > http://leves.web.elte.hu/ProcessWrapper/ProcessWrapperPlugin.dll > > But of course since the domain is down, it breaks everything. > > Not the mention downloading dll over http. > > Peter > >

Aug. 27, 2016

Re: [Pharo-dev] About better communication in the community

by stepharo

You see hernan doing positively is the best way to make that things happen We can have a preUnload hook Now we should check how it fits with cleanForProduction and others. But we should definitively have a way to express this. So let us see how we can design it and then just implement it. I'm sure that GT people are open to such hooks and if you really want to get a better Pharo for you then talk to them and us. https://pharo.fogbugz.com/f/cases/18997/Add-unload-to-package-manifest-in-QA https://pharo.fogbugz.com/f/cases/18998/Add-unload-to-package-manifest-of-S… https://pharo.fogbugz.com/f/cases/18999/Add-unload-to-package-manifest-in-G… https://pharo.fogbugz.com/f/cases/19000/Add-unload-to-package-manifest-in-GT Stef

Aug. 27, 2016

Re: [Pharo-dev] broken GitFileTree/IceBerg on Windows because of ProcessWrapper

by Guillermo Polito

Hi peter, just one note from the airport. It's Iceberg, not IceBerg. It is not a compound word, but a single one. Guille Le 27 aoÃ»t 2016 10:47, "Peter Uhnak" <i.uhnak(a)gmail.com> a Ã©crit : > Hi, > > GitFileTree / IceBerg is now broken, because ProcessWrapper (one of the > deps on Windows) is downloading plugin from > > http://leves.web.elte.hu/ProcessWrapper/ProcessWrapperPlugin.dll > > But of course since the domain is down, it breaks everything. > > Not the mention downloading dll over http. > > Peter > >

Aug. 27, 2016

Re: [Pharo-dev] About better communication in the community

by stepharo

I took the inspector from Pharo20 and I will check if it is working in Pharo. Then I will - check EyeInspector from a package perspective (extensions and the rest) - make sure that we can remove EyeInspector - package the attached file as BasicInspector. Now if you want to help you are welcome. Stef

Aug. 27, 2016

Re: [Pharo-dev] About better communication in the community

by stepharo

What we should do is to add an unload method to each of the package manifest of the corresponding projects. We should make the unload protocol a lot more present. I will start with Nautilus. > > Can you publish the unload process? > > > Workspace openContents: 'GTPlayground setGTPlaygroundEnabledStatus: false. > " ========== Debuggers ========== " > > Nautilus pluginClasses: nil. > SpecDebugger closeAllDebuggers. > GTGenericStackDebugger closeAllDebuggers. > GTGenericStackDebugger setGTDebuggerEnabledStatus: false. > > " ========== Miscellany ========== " > > GTInspector setGTInspectorEnabledStatus: false. > GTExampleOrganizer stop. > GTEventRecorder cleanUp. > GTEventRecorderSettings cleanUp. > GTSnippets reset. > GTPlayBook reset. > GTPlayBook resetDirectories. > GTSpotter cleanUp. > GTSpotterGlobalShortcut reset. > > GlobalIdentifier cleanUp. > Privacy cleanUp. > > " ========== QA ========== " > QASettings inspectorPluggin: false. > QASettings spotterPlugin: false. > QAEventCollector unload. > (MCPackage named: ''QualityAssistant'') unload. > > " ========== RPackage ========== " > RPackageOrganizer default packageNames > select: [ :each | each beginsWith: ''GT'' ] > thenDo: [ :each | > (MCPackage named: each) unload. > RPackageOrganizer default unregisterPackageNamed: each. > " Possibly unnecessary... " > Smalltalk removeEmptyMessageCategories. > Smalltalk cleanOutUndeclared. > Smalltalk fixObsoleteReferences. > Smalltalk globals flushClassNameCache ]. > > Behavior flushEvents. > Behavior flushObsoleteSubclasses. > SmalltalkImage current resetTools.' > > I still have some obsoletes around > > AnObsoleteGTSpotterGlobalShortcut . > AnObsoleteQANautilusPlugin . > AnObsoleteGTExampleFinder > AnObsoleteGTExampleOrganizer > AnObsoleteGTSpotterProfiler > AnObsoleteGTEventCollector > AnObsoleteGTExampleNotDefinedRule > > Tried to clean but no sucess so far. > >> Respect the freedom of choice for people which is not obligated >> to love all your tools, by providing an uninstall option (if the >> tool is not really essential) > I agree about the Unload.... Joseph Pelrine always told me that we > are only done when we can > upload and that the system is in a good shape. > > You may not know it because I spent days working on configuration > of RB and friends > The problems is that it is a hell to keep them up to date (because > of our image). > We should have a building process from a seed. Because like that > you experiment every single day that you loading script. > Now we did not stress enough the unload of Metacello. > > > Now you see Pharo cannot be an empty shell. > Because what will happen if we are always listening to someone > that does not like something. > Now I strongly encourage you to watch the esug talk about > bootstrap because with it and all the work > of Pavel to define configurations for all the part of the system > so people will be able to build their solutions when the > official version does not suite their needs. >> >>> >>> I would love to have the time to invite you, or any GT >>> developer, to work with me just one week with real DNA data, >>> and see how well GT goes... >> >> Please do a skype sharing session with Andrei and Doru. I'm >> sure that they will love to do it. >> So I take your words and urge you do it. >> It will help you to get out your frsutration and I'm sure >> that GT will improve. >> So a clear win/win situation. >> >> >> This is hard for me because I'm sure at this point Andrei and >> Doru should be angry with me for ciriticizing their work. > No I do not think so :) > I criticized their tools too. >> But I will try to make some use cases these days and share with >> you so I can show you specifically what I'm talking about. > Excellent! > >>> Understood, what makes me most sad is users almost accepted >>> they cannot do better and if they do, their work will never >>> be integrated by default. >> No do better. >> Why I started Spec when ther was Glamour. Why Alain was >> working on Calipso? >> I would love that someone comes and tell me: take XX it is >> super hyper cool UI Builder. >> >> >> Me too, and by this point we should really ask ourselves why we >> don't have yet a cool UI Builder. > Because nobody did it in a way that we can use it. > > One guy worked alone on a private project long time ago. We could > not give him any feedback > because he wanted to have it perfect in the first place. > He stoped to work on it because of bad table support. > I looked at it once he opened-source it and you would not like to > have the code in Pharo. > > Stef > >> >> HernÃ¡n >> >>> Instead, non-voters decisions discourages users to be >>> rewarded for their creativity, and imposes many others to >>> work free "supporting" tools which were imposed de facto. >>> >>> So again, I cannot stress this enough: Is my job to say >>> no. I know I hurt some people but social development is >>> complicated. >>> I do not think I do a bad job :) >>> >>> >>> Me neither, but you cannot expect conformity from all of us. >>> >>> HernÃ¡n >>> >>> cheers! >>> Esteban >>> >>>> On 24 Aug 2016, at 09:38, stepharo <stepharo(a)free.fr >>>> <mailto:stepharo@free.fr>> wrote: >>>> >>>> Hi Hernan >>>> >>>> First thanks for your email because we may disagree but >>>> we often agree. :) so this is an email for me. >>>>> Hi Stef, >>>>> >>>>> Good communication implies being clear when writing >>>>> about sensitive topics, especially when communicating >>>>> through virtual channels. I am not in Europe, so I >>>>> cannot discuss these things with you face to face. >>>> This is what we want to change with montly videos meeting. >>>>> Therefore is not clear to me (and others) what are >>>>> your policies in many subjects. Lately I also delayed >>>>> the release of packages because my lack of motivation >>>>> around this community, specially when discussions >>>>> exists around three or fourth topics for months. >>>> >>>> Like what? >>>> Let us know because we do not >>>>> Another "motivational" case for me. I stopped to >>>>> report bugs in fogbuz because I felt there was too >>>>> much "Won't fix" for me (specifically by a person but >>>>> I won't go there...) even in cases where it was >>>>> ilogical. Then I felt tired of reading "It's like >>>>> that. Invalid". >>>> This is a pity. >>>> I know the feeling because some of mine are close too. >>>> You are not the only victim of the "Issue closing >>>> syndrom" ;). >>>> And I would like the syndrome to be more human >>>> friendly. Thanks for raising this point. >>>> >>>> Now two points >>>> - You should always send a mail to the mailing-list >>>> and that we discuss your points. >>>> >>>> - Now what will happen if we all open bugs and none >>>> of us works on the open bugs. >>>> So what is the solution for you. I mean it concretely. >>>> How to deal with dying >>>> >>>> Looking at bugs is really difficult. There are not >>>> enough people looking and fixing bugs. >>>> >>>>> About features. >>>>> >>>>> What's the policy about voting for default features in >>>>> next Pharo images? Let's suppose I am a VM/core Pharo >>>>> maintainer and I want to include MySuperPackage into a >>>>> Pharo release, which nobody needs (and I don't care), >>>>> but it is useful to me.... there will ever be voting >>>>> there? (note it doesn't makes sense if you are a group >>>>> of 50 always supporting your work) >>>> >>>> It does not really work because engineers are paid for >>>> certain task. >>>>> Images are becoming huge (at least for my workflows). >>>>> There will be (more) packages included by default (for >>>>> promotion?) ? >>>> Thanks to raise this point because I mentioned it also >>>> to the board. So I like when I'm not alone. >>>> Now we should not see look only at the size. Doing >>>> nothing is size zero :) >>>> The point is what are the functionalities delivered. >>>> >>>> Three points: >>>> - what are the key things we want? >>>> keybinding, settings, cool inspector cool.... >>>> >>>> - how many duplicated functionality can we remove: >>>> for example I want to merge MCDefinitions with Ring >>>> with RBDefinition >>>> we removed pseudo* >>>> but this is a lot of work >>>> >>>> The goal is to throw many system when bloc and brick >>>> are ready >>>> >>>> - what is the list of things that you would remove? >>>> >>>> - with the bootstrap and all the packages of the >>>> image managed with Cargo plus the git management >>>> we believe that we will be able to manage a set of >>>> images with minimal images. >>>> - this is several years that we are working >>>> on this goal. >>>> Believe me this is the vision document not for the sake >>>> of it. >>>> >>>>> How do you plan to manage if some people want the >>>>> Tests be removed from the official Image? (Personally >>>>> I never run them) >>>> - then you use a jenkins job to produce your image >>>> where you unload the tests. >>>> >>>>> Another example, what happens if another research >>>>> group came with a better alternative to Calypso, >>>>> Brick, Telescope, Bloc. Would you integrate first your >>>>> tool to mark territory? >>>> >>>> No this is not a question of territory. Doru and GT >>>> does not do that in that spirit. >>>> RMOD too. We do something when we think that this >>>> is better. >>>> For example Epicea is three years of work of >>>> Martin, Fuel was so nice that we could not lose it. >>>> You see Ghost got changed by denis, Seamless got >>>> rewritten from scratch. >>>> >>>>> Who decides? For example (IIRC) TxText and Twisty. >>>> Igor looked at Twisty seriously and I do not think >>>> that it could handle large cobol files. >>>> >>>> (you see funnily denis is doing the same with >>>> Seamless - He rewrote it from scratch while >>>> nick worked on it for several years). >>>> >>>> Igor wanted to have a stream-based API that could >>>> work on modern command-oriented videos card framework. >>>> My team (on our own money if you understand what it >>>> means) >>>> paid Igor to build TxText (and I can tell you that >>>> I would have prefered him to do something else). >>>> >>>> >>>>> The same applies if anyone came with another rewrite >>>>> of classic Smalltalk Workspace, Debugger and Inspector >>>>> tools, what would you do with GT? GT stays because it >>>>> came before and others would be optional? >>>> No this is not like that. >>>> If you are better or answer better needs. >>>> >>>>> There will be anything like PEPs? >>>> I would love but will people have the energy to >>>> implement them? >>>> I would definitively encourage you as a community >>>> to raise points on what you need. >>>> >>>>> If someone can answer me I think that would be an >>>>> example of good communication. >>>> Hernan I always answered your emails. I always >>>> consider your work (and you know it for other reasons >>>> and by my facts) after I'm not always in agreement as >>>> I'm not always in agreement with other board members >>>> and this is how live happens. >>>> What is clear is that the most important aspects is >>>> to continue to communicate. This is why the board is >>>> launching >>>> this initiative and I would love to see it taken by >>>> people even for their projects. >>>> >>>> >>>>> >>>>> HernÃ¡n >>>>> >>>>> >>>>> 2016-08-24 1:51 GMT-03:00 stepharo <stepharo(a)free.fr >>>>> <mailto:stepharo@free.fr>>: >>>>> >>>>> Hi guys >>>>> >>>>> the board got a good discussion at ESUG about how >>>>> to improve and a lot of the discussion turned >>>>> around improving communication. We got some ideas >>>>> that we will propose soon but I would like to get >>>>> *your* ideas. >>>>> >>>>> If you have idea about improving communication >>>>> around pharo please tell us. >>>>> >>>>> >>>>> Stef >>>>> >>>>> >>>>> >>>> >>> >>> >> >> > >

Aug. 27, 2016

broken GitFileTree/IceBerg on Windows because of ProcessWrapper

by Peter Uhnak

Hi, GitFileTree / IceBerg is now broken, because ProcessWrapper (one of the deps on Windows) is downloading plugin from http://leves.web.elte.hu/ProcessWrapper/ProcessWrapperPlugin.dll But of course since the domain is down, it breaks everything. Not the mention downloading dll over http. Peter

Aug. 27, 2016

IceBerg and push for projects vs packages

by Peter Uhnak

Hi, one thing that I wanted to ask about IceBerg --- during the IceBerg talk Nico mentioned that we need to think in terms of projects. Now I understand that perspective, because that's how git behaves and that's how _I_ think, however at the same time, there is a strong push for focusing on packages... having each package describing it's dependencies, etc. So my question is, how do those two views interact with each other? Because I feel like they are going against each other. Peter

Aug. 27, 2016

Re: [Pharo-dev] CI is down

by Marcus Denker

something is in a strange stateâ¦ the update from yesterday afternoon (there should be a 194) is not there, it is very slowâ¦ but it seems to work. Sadly I am *completely* dead after esug and will be offline the weekend. Marcus > On 26 Aug 2016, at 01:05, monty <monty2(a)programmer.net> wrote: > > https://ci.inria.fr/pharo >

Aug. 27, 2016