- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] ImageSegments and some OT (was: Re: Squeak 5 Image Segment Work [was [squeak-dev] [ANN] Squeak 5])

by Marcus Denker

> On 20 Aug 2015, at 16:37, Tobias Pape <Das.Linux(a)gmx.de> wrote: > > Hi all, > > On 19.08.2015, at 23:09, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > >> Hi All, but especially Tobias, > > just for reference, I only had time to skim this mail. > I'll work through it more in-depth in September (vacation upcoming, sorry). > > Also, I like Fuel as a way forward. I'd also like to deprecate DataStreams in > favor of Fuel[1], I also had a prototype of Fuel-based Monticello packages > which loaded much faster for large packagesâ¦ > > Best regards > -Tobias > > > [1]: PS: Hi Pharo folks, MCDataStream will break with Spur, > Have a look at System-topa.741 unil System-topa.473 in the > Squeak trunk or the attached change set, YMMV tho. > Very nice! yes, back when we cleanup the 4+ different serialisers we decided to not go Fuel for Monticello for staying compatible. We therefore just took a simplified DataStream and added it as MCDataStream to Monticello itself. It would be nice to retire that once and for all! Marcus

Aug. 21, 2015

[Pharo5] Improvements for Anonymous classes

by Marcus Denker

Hi, Besides cleaning for the bootstrap, another thing we did yesterday was improving handling of Anonymous classes. 1) you can now browse methods of anonymous classes with nautilus *if* they inherit from Object (the main case) myClass := Object newAnonymousSubclass. myClass compile: 'test ^5'. myClass browse 2) #classInstaller for anonymous classes now returns an AnonymousClassInstaller 3) class builder name checking was fixed to not raise an error for the ânamesâ used for Anonymous classes ==> you can use #addSlot: on anonymous classes. To improve: - browser should show some kind of class definition so one can see the superclass - it would be nice to be able to browse "Behavior newâ, but in most cases people use anon subclasses of existing classes, so not that important. Marcus

Aug. 21, 2015

Re: [Pharo-dev] RMoD page partially broken

by Marcus Denker

Hi, Thanks for the note, yes, we know. It will be fixed soon (after holidays are over) Marcus > On 20 Aug 2015, at 19:11, Max Leske <maxleske(a)gmail.com> wrote: > > Hi guys > > I see that there seem to be issues on the RMoD web page (missing CSS, 404 on certain links etc.). > Thought Iâd let you know. > > Cheers, > Max

Aug. 21, 2015

Re: [Pharo-dev] [pharo-core] 50248 (3d7f1f3)

by Marcus Denker

> On 20 Aug 2015, at 22:29, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > > Hi Bernardo, > I would say no: don't revert anything before testing. Yes, we should benchmarkâ¦ and this shows that if people write âspecialâ fast code, they *really* need to document this! Now with the quality assist in place, you will find people submitting improvements for âbadâ code all the time. It will be impossible to not clean if these cases are not well documented. > > 2015-08-20 19:56 GMT+02:00 Bernardo Ezequiel Contreras <vonbecmann(a)gmail.com <mailto:vonbecmann@gmail.com>>: > Hi all, > > it seems i have changed a method (Rectangle>>#intersect:ifNone:) that could impact in the performance of the UI. see below > > ---------- Forwarded message ---------- > From: Nicolas Cellier <notifications(a)github.com <mailto:notifications@github.com>> > Date: Thu, Aug 20, 2015 at 1:18 PM > Subject: Re: [pharo-core] 50248 (3d7f1f3) > To: pharo-project/pharo-core <pharo-core(a)noreply.github.com <mailto:pharo-core@noreply.github.com>> > > > IMO, min: and max: were intentionally inlined for speed purpose, since primitive graphics objects are heavily used. > That's questionnable, but maybe still necessary on slow machines like Pi. > > â > Reply to this email directly or view it on GitHub <https://github.com/pharo-project/pharo-core/commit/3d7f1f3ac45310096f565c2d…>. > > > so, do i have to revert that change? > > thanks, sorry for the inconvenience > > > -- > Bernardo E.C. > > Sent from a cheap desktop computer in South America. >

Aug. 21, 2015

Re: [Pharo-dev] Design Question: Undefined vs. MyNullObject vs. #ifNil:

by Nicolai Hess

2015-08-20 23:03 GMT+02:00 Sean P. DeNigris <sean(a)clipperadams.com>: > > I'm working on Issue 16136: "DateModel: Allow nil" > https://pharo.fogbugz.com/default.asp?16136 > > The idea is that DateModel should allow the possibility of no date (i.e. > date = nil) because some applications require this. > > Here are three possible implementations: > 1. #ifNil: checks; I already implemented this simple solution in > Spec-PolyWidgets-SeanDeNigris.59 (Pharo 4.0 based) and committed to > http://smalltalkhub.com/mc/SeanDeNigris/SeansOutbox/main/ > 2. Use UndefinedObject as a null object; this would probably require adding > an extension message to both Date and UndefinedObject, because it must be > specific enough not to reasonably conflict with other users > 3. Use a custom NoDate Null Object; the obvious advantage is that Date > remains unchanged, and NoDate just gets a (very) partial implementation of > its protocol; the disadvantage is that an extra class is introduced into > Core. > > Which, as a general guideline, do we prefer in Core? #3 seems to be the > universal OOP advice, butâ¦ > > I think this highly depens on how *useful* the null object would be, apart from being a "no-date". For example, if the user of the DateModel only use the string representation of the Date/NoDate object, they don't have to care about the real type, either they get a date string (21 August 2015) or an empty string. But the usage of Date objects is too general, the user of the DateModel will end up with replacing ifNil-checks with ifNullDate-checks. > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Design-Question-Undefined-vs-MyNullObject-vs-ifNil-tp… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

Aug. 21, 2015

Re: [Pharo-dev] Design Question: Undefined vs. MyNullObject vs. #ifNil:

by Ben Coman

On Fri, Aug 21, 2015 at 5:03 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I'm working on Issue 16136: "DateModel: Allow nil" > https://pharo.fogbugz.com/default.asp?16136 > > The idea is that DateModel should allow the possibility of no date (i.e. > date = nil) because some applications require this. > > Here are three possible implementations: > 1. #ifNil: checks; I already implemented this simple solution in > Spec-PolyWidgets-SeanDeNigris.59 (Pharo 4.0 based) and committed to > http://smalltalkhub.com/mc/SeanDeNigris/SeansOutbox/main/ > 2. Use UndefinedObject as a null object; this would probably require adding > an extension message to both Date and UndefinedObject, because it must be > specific enough not to reasonably conflict with other users > 3. Use a custom NoDate Null Object; the obvious advantage is that Date > remains unchanged, and NoDate just gets a (very) partial implementation of > its protocol; the disadvantage is that an extra class is introduced into > Core. > > Which, as a general guideline, do we prefer in Core? #3 seems to be the > universal OOP advice, butâ¦ What is you definition of Core? The standard released Image, or some minimal part? I suppose any extension message you might add for (2.) could just be added for (3.), so I see no advantage to that. (3.) facilitates a better paradigm for user-code, so is preferable. What is disadvantages you you perceive with adding an extra class? I can only think memory size, but you save code size eliminating #ifNil(s) from user-code cheers -ben

Aug. 21, 2015

Re: [Pharo-dev] Status of Tanker?

by HernÃ¡n Morales Durand

Hi Mariano, 2015-08-20 15:54 GMT-03:00 Mariano Martinez Peck <marianopeck(a)gmail.com>: > > > On Thu, Aug 20, 2015 at 3:49 PM, HernÃ¡n Morales Durand < > hernan.morales(a)gmail.com> wrote: > >> Hello Max, >> >> 2015-08-20 15:15 GMT-03:00 Max Leske <maxleske(a)gmail.com>: >> >>> >>> On 20 Aug 2015, at 19:38, HernÃ¡n Morales Durand < >>> hernan.morales(a)gmail.com> wrote: >>> >>> Hello MartÃn >>> >>> >>> 2015-08-20 5:31 GMT-03:00 Martin Dias <tinchodias(a)gmail.com>: >>> >>>> Hello HernÃ¡n, >>>> >>>> It's outdated, we were not taking care of Tanker. I've just updated >>>> some urls in the doc, and the Pharo versions in the Jenkins job (it was >>>> being run in 2.0 and 3.0!). >>>> >>>> BTW, have you loaded it from this repo? >>>> >>>> http://smalltalkhub.com/#!/~PharoExtras/Tanker >>>> >>>> >>> Yes. >>> >>> I checked the code and PackageInfo usage was intentional >>> (#behaviorsLocalToPackageInfoNamed: , #extensionMethodsToPackageInfoNamed: >>> , etc) , but the tests are generating AnObsoleteClassForTestToBeDeleted... >>> and from there I don't know. >>> >>> >>> Thatâs something weâve fixed in Fuel. Itâs simply a side effect of the >>> tests, not a functional problem. >>> >>> >> Good :) >> >> >>> >>> Is just that PackageInfo stuff preventing to use Tanker? >>> >>> >>> I guess Tanker would need to be updated for the changes in >>> CompiledMethod and possibly a couple of changes would be required to >>> account for deprecation etc. >>> Iâm not sure how much work it would take to use RPackage / Ring. >>> >>> >> I hope it is not too much work. >> >> >>> Could you comment how far is Tanker from being stable or usable? >>> >>> >>> I guess we could make it work within a couple of hours / days. So far >>> there was simply no interest from anybody AFAIK. >>> >>> Whatâs your use case exactly? >>> >>> >> Building my PhyloclassTalk app loads > 60 packages and it is taking too >> much time. I read about loading Seaside in 10 sec. so I want that too :) >> >> > One of the problems that never got fixed in Tanker was that if the > superclass of a class you are loading has changed instVars from where you > have exported, then the compiled methods will be wrong and bytecodes will > access a shifted instvar (this is one of the scenarios, but there are a > couple). Of course, nice solutions could be developed to even avoid > compilation (I remember Marcus telling us to get IR -- intermediate > representation -- from compiled method, then change instVas, and get new > compiled method. But... even without that, we still never developed the > most basic solution which would detect such a case and do a normal > compilation from source (source is ALSO serialized anyway). Until we > develop that, I think it won't be stable. > > > Thank you for the detailed explanation. HernÃ¡n > > >> Another situation is when I show Pharo to solve "easy" tasks (CSV, >> PetitParser, etc) to people and it doesn't feel nice to wait loading, >> specially when Python takes 2 secs to install with pip, or they use >> IPython/anaconda which has everything preloaded. >> >> Cheers, >> >> HernÃ¡n >> >> >>> Cheers, >>> Max >>> >>> >>> HernÃ¡n >>> >>> >>>> (we moved from Mariano's repo, but the old one wasn't deleted). >>>> >>>> Cheers, >>>> MartÃn >>>> >>>> >>>> >>>> >>>> El jue., 20 ago. 2015 a las 8:24, HernÃ¡n Morales Durand (< >>>> hernan.morales(a)gmail.com>) escribiÃ³: >>>> >>>>> Hello, >>>>> >>>>> What is the status of Tanker? >>>>> I tried to loadDevelopment in Pharo 4 but there are references to >>>>> PackageInfo, and tests fails. >>>>> Cheers, >>>>> >>>>> HernÃ¡n >>>>> >>>>> >>>>> >>> <TankerPackagesSupport-HernanMoralesDurand.11.mcz> >>> >>> >>> >> > > > -- > Mariano > http://marianopeck.wordpress.com >

Aug. 20, 2015

Re: [Pharo-dev] WhatsUp from: 2015-08-17 until: 2015-08-31

by Dimitris Chloupis

Thanks for the link, I am also interested into Bloc. On Thu, Aug 20, 2015 at 11:37 PM Tudor Girba <tudor(a)tudorgirba.com> wrote: > Hi, > > The comment is about the fact that Workspace tends to imply that this is > the only place where work is being done, and the old incarnation of the > Workspace is incorrect on this topic. > > What we are doing is very much a work in progress. The current effort is > on the widget set on top of Bloc and then we will move to the tools. We > will follow up with more details soon on that. > > In the meantime, you can see the development image here: > > https://ci.inria.fr/moose/job/gtoolkit5/lastSuccessfulBuild/artifact/gtoolk… > > Cheers, > Doru > > > > On Thu, Aug 20, 2015 at 12:11 PM, Dimitris Chloupis <kilon.alios(a)gmail.com > > wrote: > >> Tudor this great news, I was not aware you guys were moving to a similar >> direction because of that class comment. Where I can follow your progress , >> is it added directly to Moose or is there a special repo for these >> enhancements ? I would hate to waste time coding something you will be >> coding too. Its not as if I am going to implement these features any time >> soon anyway. >> >> On Thu, Aug 20, 2015 at 1:05 PM Dimitris Chloupis <kilon.alios(a)gmail.com> >> wrote: >> >>> I was thinking something similar. Its not a crazy idea at all. Auto >>> completion already has a detailed view for class comments if its enabled in >>> settings. However a more minimal gui will be needed not to make the life of >>> the user difficult . >>> >>> On Thu, Aug 20, 2015 at 12:36 PM Denis Kudriashov <dionisiydk(a)gmail.com> >>> wrote: >>> >>>> Hi >>>> >>>> 2015-08-20 6:54 GMT+03:00 Dimitris Chloupis <kilon.alios(a)gmail.com>: >>>> >>>>> >>>>>> Auto-completion in Pharo is really bad. It would be fantastic to >>>>>> improve it. >>>>>> >>>>>> >>>>> Yes indeed, my effort for now is focused in documenting it. I cannot >>>>> improve what I dont understand. Then will see if I can improve it, by >>>>> making it more customizable or making it a bit smarter. >>>>> >>>> >>>> I have crazy idea to integrate GTSpotter to autocompletion pane to >>>> allow immediate search on existed texts. What you think about this? >>>> >>> > > > -- > www.tudorgirba.com > > "Every thing has its own flow" >

Aug. 20, 2015

Re: [Pharo-dev] Status of Tanker?

by Martin Dias

HernÃ¡n, thanks for the contribution, I copied it to the repository. I think you can commit without any special permission. I took a look in the errors and I found that it uses SourceFilesArray API that we removed in Pharo 5.0... indeed, in Tanker we made strong assumptions about the changes files. I did a pass migrating code to current Pharo (50249). Mariano: yes, we didn't implement recompilation when something changed in the format. Max: I agree Tanker has to use RPackage instead of PackageInfo, but I'm not sure it needs to be moved to Ring. MartÃn El jue., 20 ago. 2015 a las 21:22, Max Leske (<maxleske(a)gmail.com>) escribiÃ³: > On 20 Aug 2015, at 20:49, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> > wrote: > > Hello Max, > > 2015-08-20 15:15 GMT-03:00 Max Leske <maxleske(a)gmail.com>: > >> >> On 20 Aug 2015, at 19:38, HernÃ¡n Morales Durand <hernan.morales(a)gmail.com> >> wrote: >> >> Hello MartÃn >> >> >> 2015-08-20 5:31 GMT-03:00 Martin Dias <tinchodias(a)gmail.com>: >> >>> Hello HernÃ¡n, >>> >>> It's outdated, we were not taking care of Tanker. I've just updated some >>> urls in the doc, and the Pharo versions in the Jenkins job (it was being >>> run in 2.0 and 3.0!). >>> >>> BTW, have you loaded it from this repo? >>> >>> http://smalltalkhub.com/#!/~PharoExtras/Tanker >>> >>> >> Yes. >> >> I checked the code and PackageInfo usage was intentional >> (#behaviorsLocalToPackageInfoNamed: , #extensionMethodsToPackageInfoNamed: >> , etc) , but the tests are generating AnObsoleteClassForTestToBeDeleted... >> and from there I don't know. >> >> >> Thatâs something weâve fixed in Fuel. Itâs simply a side effect of the >> tests, not a functional problem. >> >> > Good :) > > >> >> Is just that PackageInfo stuff preventing to use Tanker? >> >> >> I guess Tanker would need to be updated for the changes in CompiledMethod >> and possibly a couple of changes would be required to account for >> deprecation etc. >> Iâm not sure how much work it would take to use RPackage / Ring. >> >> > I hope it is not too much work. > > >> Could you comment how far is Tanker from being stable or usable? >> >> >> I guess we could make it work within a couple of hours / days. So far >> there was simply no interest from anybody AFAIK. >> >> Whatâs your use case exactly? >> >> > Building my PhyloclassTalk app loads > 60 packages and it is taking too > much time. I read about loading Seaside in 10 sec. so I want that too :) > > > Well yes but thatâs only possible if you first export the code in the > Tanker format. And you donât want to do that for every new version (unless > of course, Tanker were the default formatâ¦). > > > Another situation is when I show Pharo to solve "easy" tasks (CSV, > PetitParser, etc) to people and it doesn't feel nice to wait loading, > specially when Python takes 2 secs to install with pip, or they use > IPython/anaconda which has everything preloaded. > > > I know what you mean. We have builds on our build server that take up to > 30 minutes. I once thought to have multiple stages of builds to reduce > build times but that wont work in this case of course. > > > Cheers, > > HernÃ¡n > > >> Cheers, >> Max >> >> >> HernÃ¡n >> >> (we moved from Mariano's repo, but the old one wasn't deleted). >> >> Cheers, >> MartÃn >> >> >> >> >> El jue., 20 ago. 2015 a las 8:24, HernÃ¡n Morales Durand (< >> hernan.morales(a)gmail.com>) escribiÃ³: >> Hello, >> >> What is the status of Tanker? >> I tried to loadDevelopment in Pharo 4 but there are references to >> PackageInfo, and tests fails. >> Cheers, >> >> HernÃ¡n >> >> >> >> <TankerPackagesSupport-HernanMoralesDurand.11.mcz> >> >>

Aug. 20, 2015

Re: [Pharo-dev] issue 16191 Low-level packages should not include tests

by stepharo

Hi nicolai Guillermo told me that this is a problem with RPackage and that the current solution was to reset RPackage from Mc I do not really like the solution. Now I do not have the cycles to have a look at the problem. What I saw is a stack trace in one of the red ci attempts today that could help to find the problem. Stef > somehow this "Tests-"tag extraction does not work > (see 15861 Create test package for Jobs) > > Even if we promote the Tests-tag as a package and creating the slice, > merging the slice again creates a tag in the original package. > > any ideas?

Aug. 20, 2015