- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Call of projects of open-dev lectures

by Damien Pollet

Perhaps the most important is that the project has maintainers who can be reasonably reactive (so that the students can at least interact and get feedback on a weekly basis). If you can identify beginner-friendly issues and tasks, that would be great too. On 4 January 2017 at 16:41, Serge Stinckwich <serge.stinckwich(a)gmail.com> wrote: > PolyMath issues are here: > > https://github.com/PolyMathOrg/PolyMath/issues > > > > On Wed, Jan 4, 2017 at 3:48 PM, Stephane Ducasse > <stepharo.self(a)gmail.com> wrote: > > Hi > > > > We are organising a lecture where students should > > - learn pharo > > - learn how to communicate with open source community > > - learn how to reverse engineer, fix bugs.... > > They should work by 3/4. > > > > We are looking for projects that would like to accept > > - propose some bugs to be fixed > > - to communicate with newbies and from time to time > > > > I was thinking about > > - MDL > > - Roassal > > - Moose ? > > - Pillar ? but nobody beside me and I do not have the time > > - DRGeoII > > - Telescope > > - Artefact > > - Scale > > - Ecstatic > > > > So if you have a project and you want to participate. > > We would like to have > > - web page? > > - mailing-list > > - bug trackers/todo? > > > > Stef > > > > -- > Serge Stinckwich > UCBN & UMI UMMISCO 209 (IRD/UPMC) > Every DSL ends up being Smalltalk > http://www.doesnotunderstand.org/ > > -- Damien Pollet type less, do more [ | ] http://people.untyped.org/damien.pollet

Jan. 4, 2017

Re: [Pharo-dev] Call of projects of open-dev lectures

by Serge Stinckwich

PolyMath issues are here: https://github.com/PolyMathOrg/PolyMath/issues On Wed, Jan 4, 2017 at 3:48 PM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi > > We are organising a lecture where students should > - learn pharo > - learn how to communicate with open source community > - learn how to reverse engineer, fix bugs.... > They should work by 3/4. > > We are looking for projects that would like to accept > - propose some bugs to be fixed > - to communicate with newbies and from time to time > > I was thinking about > - MDL > - Roassal > - Moose ? > - Pillar ? but nobody beside me and I do not have the time > - DRGeoII > - Telescope > - Artefact > - Scale > - Ecstatic > > So if you have a project and you want to participate. > We would like to have > - web page? > - mailing-list > - bug trackers/todo? > > Stef -- Serge Stinckwich UCBN & UMI UMMISCO 209 (IRD/UPMC) Every DSL ends up being Smalltalk http://www.doesnotunderstand.org/

Jan. 4, 2017

Re: [Pharo-dev] Call of projects of open-dev lectures

by Dimitris Chloupis

My project may be too advanced for a student but if students are interested in Game Development and Unreal , it can a very fun experience for them. I am in a process of constructing a Unreal API for Pharo. What students can learn 1) How to combine Pharo with C++ 2) How to use Unreal 3) How to use Pharo's UFFI 4) How to utilize shared memory and sockets 5) How to generate 3D graphics using Blender 6) How to profile Pharo 7) How to use git and github And a ton more, game development is a massive field What is required 1) basic knowledge of Pharo 2) basic knowledge of C++ Main website http://www.kilon-alios.com Github repos https://github.com/kilon/Ephestos (umbrella project) https://github.com/kilon/CPP (tool for using Unreal from Pharo) Online chat Slack - Ephestos room , or Discord Mailing list Github issues page of Ephestos can be used as forum On Wed, 4 Jan 2017 at 16:49, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Hi > > We are organising a lecture where students should > - learn pharo > - learn how to communicate with open source community > - learn how to reverse engineer, fix bugs.... > They should work by 3/4. > > We are looking for projects that would like to accept > - propose some bugs to be fixed > - to communicate with newbies and from time to time > > I was thinking about > - MDL > - Roassal > - Moose ? > - Pillar ? but nobody beside me and I do not have the time > - DRGeoII > - Telescope > - Artefact > - Scale > - Ecstatic > > So if you have a project and you want to participate. > We would like to have > - web page? > - mailing-list > - bug trackers/todo? > > Stef >

Jan. 4, 2017

Call of projects of open-dev lectures

by Stephane Ducasse

Hi We are organising a lecture where students should - learn pharo - learn how to communicate with open source community - learn how to reverse engineer, fix bugs.... They should work by 3/4. We are looking for projects that would like to accept - propose some bugs to be fixed - to communicate with newbies and from time to time I was thinking about - MDL - Roassal - Moose ? - Pillar ? but nobody beside me and I do not have the time - DRGeoII - Telescope - Artefact - Scale - Ecstatic So if you have a project and you want to participate. We would like to have - web page? - mailing-list - bug trackers/todo? Stef

Jan. 4, 2017

Re: [Pharo-dev] Deprecations on Smalltalk Image in Pharo 5

by Henrik Johansen

> On 3 Jan 2017, at 22:40 , Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > > > On Tue, Jan 3, 2017 at 8:56 PM, Eliot Miranda <eliot.miranda(a)gmail.com <mailto:eliot.miranda@gmail.com>> wrote: > > > On Tue, Jan 3, 2017 at 2:24 AM, Henrik Johansen <henrik.s.johansen(a)veloxit.no <mailto:henrik.s.johansen@veloxit.no>> wrote: > It was my impression there was a procedure in place earlier for moving methods from SmalltalkImage to classes with a more singular responsibility that ensures a smooth upgrade experience; > > Yes, but it depends mostly on the user and there is no automated check for it... > So it happens that people (myself also) sometimes remove stuff without going into the deprecation phase... :/ > > > 1) create accessor method on Smalltalk (if none of the existing are appropriate) > 2) implement the old methods on new class in backwards compatability category > 3) Deprecate method on SmalltalkImage, on the form: > doX: someThing > self deprecated: 'Use Smalltalk specializedArea x: someThing instead' on: 'foo' in: 'bar'. > ^self specializedArea x: someThing > > (Ref: #os, #vm) > > I don't think step 1 is mandatory. Actually I would say it should be forbidden. > Why should Smalltalk be a facade for every library in the system? > > I agree however that for library/method rewrites we should at least keep the old interface if possible. Now, when it happens that the new API is not compatible with the old one, only the migration should be nicely documented... Not every library, and definitely not as the default for any new functionality, but (imho) at least for preexisting functionality on SmalltalkImage that is moved, ref the original discussion: http://forum.world.st/SmalltalkImage-current-vs-Smalltalk-td1574575i20.html <http://forum.world.st/SmalltalkImage-current-vs-Smalltalk-td1574575i20.html> > > > I've run into a few cases where this is not the case when moving to Pharo 5, should they be changed, or am I wrong, and the procedure above is no longer considered valuable? > > Case 1: > SmalltalkImage removeFromShutDownList: aClass (and removeFromStartUpList:) > self deprecated: > 'Please use registration methods provided in SessionManager / registration category.', > String cr, > 'ex: SessionManager default unregisterClassNamed: self name'. > > There's a new #session accessor on SmalltalkImage, but... > 1) SessionManager does not implement a backwards compatible protocol. > > I'd say that's life... > > 2) The deprecated message above is wrong, the Smalltalk session unregisterClassNamed: is preferrable to referencing the class directly. > > And that this requires a fix om the docs. > > 3) The deprecated method does nothing, rather than redirect to the new place. Silent errors when deprecation warnings are turned of, yay. > > Well redirection should be done wether it is possible. > But if it is not, then the method should be cancelled with an exception? Like that even if the deprecation is ignored, the error does not go silent. I guess the point I was trying to make; even if it's rare to unregister from startup/shutdown individually, and the new recommended approach is to use unregisterClass: to do both, when you replace such core functionality, you *need* to provide a backwards compatible protocol as well (especially since there's no 1-1 mapping between existing and previous behaviour), not just refer to unregisterClass: and let the old usage (potentially) silently do nothing. When there's still a caller in the *base* image (#deinstall in InputEventFetcher), you know the frequency by which this code is actually called/tested. Sampling the Pharo5 version of a major package like Seaside, the included GrPharoPlatform still does removeFromStartUpList: anObject "Remove anObject from the startup list in the system." Smalltalk removeFromStartUpList: anObject Would it be tested in time for the version where the deprecated method is actually removed? No one knows. But in the mean time, trying to remove Seaside, or any other existing package which tries to play nice and unregister itself, will not clean up correctly when you press proceed, as is expected when you encounter a deprecation warning. The less nice alternative, is indeed to raise an exception after the deprecation, indicating this *must* be rewritten now to continue working as intended. > > 4) The deprecation message uses the deprecated form which does not include the parameters needed to know when to expect it removed forever. > > Did not get this one deprecated: tells you nothing about when, and in which version, the method was considered obsolete. By using the expanded deprecated:on:in:, it's easier to tell when it should be expected to be gone for good (for instance, if it says it was deprecated in: 'Pharo5', you'd expect to have to migrate code by the time Pharo7 rolls around) http://forum.world.st/what-about-deprecating-deprecated-td2306905.html > > > Also, the corresponding addTo... methods have not been deprecated, but redirect to SessionManager directly rather than through #session... > > Case 2: > EndianDetector: Used to be Smalltalk #endianness > > 1) The method on SmalltalkImage has simply been removed, no deprecation. > > I agree we should've deprecated. > Maybe we can deprecate it now in Pharo6 for Pharo7 (before removing the methods from Smalltalk definitively?) Not backporting such a missing deprecation to Pharo5 would sort of defeat the purpose of using deprecations to ensure a smooth upgrade experience, no? Cheers, Henry

Jan. 4, 2017

Re: [Pharo-dev] [Ann] Calypso system browser

by Denis Kudriashov

2017-01-04 8:32 GMT+01:00 Ben Coman <btc(a)openinworld.com>: > Also... > 8. Select ASTCacheReset > 9. Tick "inherited methods" > 10. Select #addIfNotPresent:ifPresentDo: without expanding any method > groups > ==> "inherited methods" and "extensions" are highlighted, which is okay > > but now... > 11. Expanding "extensions" > ==> Collections not highlighted, and extensions lost it highlight > Yes, it is known issue which I think explain others from your feedback too. Problem that now highlighting is not restored as selection. For example if you select accessing group and then expand inherited methods (which is first) selection will stay correct although accessing is now shifted. I not put same logic for highlighting just to save time. It is feature kind of "nice to have" but not really critical IMO. So it is for future

Jan. 4, 2017

Re: [Pharo-dev] [Ann] Calypso system browser

by Ben Coman

On Tue, Jan 3, 2017 at 8:40 PM, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > 2016-12-31 16:57 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >> Maybe it is the checkbox doubling the size of the whitespace (??) such >> that it would be better placed to the right (??), or maybe I just need >> to adapt. > > > In last version (dev) I push it to the right. That for giving this a go. It looks good when "inherited methods" is unexpanded. When expanded, at first I wasn't sure about the other checkboxes remaining left-aligned, but I think its fine and actually an advantage since "inherited methods" checkbox is a slightly different function to the per-superclass checkbox. btw I think pushing the per-superclass checkbox to the right wouldn't work. > Also I moved extensions group to the top at second place. I think this works well. > And all groups now support highlighting as owner of selected methods Cool. I tried this... 1. Select AST-Core > ASTCache 2. Tick "inherited methods" then expand it and "extensions" 3. Select #addIfNotPresent:ifPresentDo: ==> highlights "inherited methods", "Collection", "extensions" and "Fuel" Not sure if all four should be highlighted but its okay. and something tricky... 4. Select Fuel 5. Select #fuelAccept: 6. Click Fuel to unselect it ==> Fuel keeps a highlight, which is very nice. however... 7. Select Fuel again and unclick it ==> Fuel has lost its highlight. Also... 8. Select ASTCacheReset 9. Tick "inherited methods" 10. Select #addIfNotPresent:ifPresentDo: without expanding any method groups ==> "inherited methods" and "extensions" are highlighted, which is okay but now... 11. Expanding "extensions" ==> Collections not highlighted, and extensions lost it highlight 12. Expanding "inherited methods" ==> WeakIdentityKeyDictionary highlighted rather than expected Collection highlight "inherited methods" remains highlighted, which is different behaviour to "extensions" at step 11. cheers -ben

Jan. 4, 2017

Re: [Pharo-dev] Deprecations on Smalltalk Image in Pharo 5

by Eliot Miranda

Hi Guille, On Tue, Jan 3, 2017 at 1:40 PM, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > On Tue, Jan 3, 2017 at 8:56 PM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: >> >> On Tue, Jan 3, 2017 at 2:24 AM, Henrik Johansen < >> henrik.s.johansen(a)veloxit.no> wrote: >> > [snip] > 2) Accessor remains the same, but all references in the base image has >>> been rewritten to use EndianDetector directly... >>> 2) Would not Smalltalk platform be a reasonable place to put this >>> responsiblity, letting it use an EndianDetector behind the scenes? Both the >>> preexisting #endianness, as well as the new #isLittleEndian and >>> #isBigEndian? >> >> > Here I am not sure of agreeing. > > Going through Smalltalk is evil. > > Maybe asking the platform is better, to hide the "EndianDetector". > > >> +1. EndianDetector is a monstrosity. >> > > Ok, EndianDetector is maybe an ugly name. > No, that's not the reason this is a monstrosity. Extracting one method into a class of its own, a method that answers something trivial, that as Hwnrik points out is logically to do with Smalltalk platform, that's what's a monstrosity. I could care less what its called. But it gratuitously broke lots of code that used it in a very ugly way while adding a large overhead for trivial functionality. It's a monstrosity. > But it has a reason to be. Before, to test endianess the system used a > Bitmap. And we wanted a standalone class that we could use whether Bitmap > is there or not (by becoming an instance of a float into a bitmap or so... > I don't remember the details). > Yeah, well, there's a VM parameter, there are no end of ways to compute it, but the point is, it can be a single method on Smalltalk platform not a whole class. _,,,^..^,,,_ best, Eliot

Jan. 4, 2017

Re: [Pharo-dev] Deprecations on Smalltalk Image in Pharo 5

by Guillermo Polito

On Tue, Jan 3, 2017 at 8:56 PM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: > > > On Tue, Jan 3, 2017 at 2:24 AM, Henrik Johansen < > henrik.s.johansen(a)veloxit.no> wrote: > >> It was my impression there was a procedure in place earlier for moving >> methods from SmalltalkImage to classes with a more singular responsibility >> that ensures a smooth upgrade experience; >> > Yes, but it depends mostly on the user and there is no automated check for it... So it happens that people (myself also) sometimes remove stuff without going into the deprecation phase... :/ > 1) create accessor method on Smalltalk (if none of the existing are >> appropriate) >> 2) implement the old methods on new class in backwards compatability >> category >> 3) Deprecate method on SmalltalkImage, on the form: >> doX: someThing >> self deprecated: 'Use Smalltalk specializedArea x: someThing >> instead' on: 'foo' in: 'bar'. >> ^self specializedArea x: someThing >> >> (Ref: #os, #vm) >> > I don't think step 1 is mandatory. Actually I would say it should be forbidden. Why should Smalltalk be a facade for every library in the system? I agree however that for library/method rewrites we should at least keep the old interface if possible. Now, when it happens that the new API is not compatible with the old one, only the migration should be nicely documented... >> I've run into a few cases where this is not the case when moving to Pharo >> 5, should they be changed, or am I wrong, and the procedure above is no >> longer considered valuable? >> >> Case 1: >> SmalltalkImage removeFromShutDownList: aClass (and removeFromStartUpList:) >> self deprecated: >> 'Please use registration methods provided in >> SessionManager / registration category.', >> String cr, >> 'ex: SessionManager default unregisterClassNamed: self >> name'. >> >> There's a new #session accessor on SmalltalkImage, but... >> 1) SessionManager does not implement a backwards compatible protocol. >> > I'd say that's life... > 2) The deprecated message above is wrong, the Smalltalk session >> unregisterClassNamed: is preferrable to referencing the class directly. >> > And that this requires a fix om the docs. > 3) The deprecated method does nothing, rather than redirect to the new >> place. Silent errors when deprecation warnings are turned of, yay. >> > Well redirection should be done wether it is possible. But if it is not, then the method should be cancelled with an exception? Like that even if the deprecation is ignored, the error does not go silent. > 4) The deprecation message uses the deprecated form which does not include >> the parameters needed to know when to expect it removed forever. >> > Did not get this one > >> Also, the corresponding addTo... methods have not been deprecated, but >> redirect to SessionManager directly rather than through #session... >> >> Case 2: >> EndianDetector: Used to be Smalltalk #endianness >> >> 1) The method on SmalltalkImage has simply been removed, no deprecation. >> > I agree we should've deprecated. Maybe we can deprecate it now in Pharo6 for Pharo7 (before removing the methods from Smalltalk definitively?) > 2) Accessor remains the same, but all references in the base image has >> been rewritten to use EndianDetector directly... >> 2) Would not Smalltalk platform be a reasonable place to put this >> responsiblity, letting it use an EndianDetector behind the scenes? Both the >> preexisting #endianness, as well as the new #isLittleEndian and >> #isBigEndian? > > Here I am not sure of agreeing. Going through Smalltalk is evil. Maybe asking the platform is better, to hide the "EndianDetector". > +1. EndianDetector is a monstrosity. > Ok, EndianDetector is maybe an ugly name. But it has a reason to be. Before, to test endianess the system used a Bitmap. And we wanted a standalone class that we could use whether Bitmap is there or not (by becoming an instance of a float into a bitmap or so... I don't remember the details). So, it is a badly name little child only. We can rename it. Suggestions? > >> Cheers, >> Henry >> > > _,,,^..^,,,_ > best, Eliot >

Jan. 3, 2017

Re: [Pharo-dev] Deprecations on Smalltalk Image in Pharo 5

by Eliot Miranda

On Tue, Jan 3, 2017 at 2:24 AM, Henrik Johansen < henrik.s.johansen(a)veloxit.no> wrote: > It was my impression there was a procedure in place earlier for moving > methods from SmalltalkImage to classes with a more singular responsibility > that ensures a smooth upgrade experience; > 1) create accessor method on Smalltalk (if none of the existing are > appropriate) > 2) implement the old methods on new class in backwards compatability > category > 3) Deprecate method on SmalltalkImage, on the form: > doX: someThing > self deprecated: 'Use Smalltalk specializedArea x: someThing > instead' on: 'foo' in: 'bar'. > ^self specializedArea x: someThing > > (Ref: #os, #vm) > > I've run into a few cases where this is not the case when moving to Pharo > 5, should they be changed, or am I wrong, and the procedure above is no > longer considered valuable? > > Case 1: > SmalltalkImage removeFromShutDownList: aClass (and removeFromStartUpList:) > self deprecated: > 'Please use registration methods provided in > SessionManager / registration category.', > String cr, > 'ex: SessionManager default unregisterClassNamed: self > name'. > > There's a new #session accessor on SmalltalkImage, but... > 1) SessionManager does not implement a backwards compatible protocol. > 2) The deprecated message above is wrong, the Smalltalk session > unregisterClassNamed: is preferrable to referencing the class directly. > 3) The deprecated method does nothing, rather than redirect to the new > place. Silent errors when deprecation warnings are turned of, yay. > 4) The deprecation message uses the deprecated form which does not include > the parameters needed to know when to expect it removed forever. > > Also, the corresponding addTo... methods have not been deprecated, but > redirect to SessionManager directly rather than through #session... > > Case 2: > EndianDetector: Used to be Smalltalk #endianness > > 1) The method on SmalltalkImage has simply been removed, no deprecation. > 2) Accessor remains the same, but all references in the base image has > been rewritten to use EndianDetector directly... > 2) Would not Smalltalk platform be a reasonable place to put this > responsiblity, letting it use an EndianDetector behind the scenes? Both the > preexisting #endianness, as well as the new #isLittleEndian and > #isBigEndian? > +1. EndianDetector is a monstrosity. > Cheers, > Henry > _,,,^..^,,,_ best, Eliot

Jan. 3, 2017