January 2014 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] NativeBoost unloading?

by Igor Stasenko

On 10 January 2014 13:59, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > > 2014/1/10 Igor Stasenko <siguctua(a)gmail.com> > >> >> On 10 January 2014 11:48, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: >> >>> NativeBoost and AsmJit are quite problematic to unload. >>> >> >> problematic, why? >> > > with the right oder it's doable: > > | remove | > remove := #('Athens-Cairo' 'PangoCairo' 'NativeBoost-Tests' > 'NativeBoost-Examples' 'NativeBoost-Unix' 'NativeBoost-Win32' > 'NativeBoost-Mac' 'NativeBoost-Core' 'NativeBoost-Pools' 'AsmJit-Tests' > 'AsmJit-StackManagement' 'AsmJit-Operands' 'AsmJit-x86' 'AsmJit-Extension' > 'AsmJit-Instructions' 'AsmJit-Core'). > > remove do: [ :packageName | > (MCWorkingCopy forPackage: (MCPackage named: packageName)) unload. ]. > > > why we do unloading like that? one must not manually specify order nor different subpackages to unload (e.g. it makes no sense to keep AsmJit-Extension if you unload AsmJit-Core etc). it should be done by configuration, or system itself should maintain knowledge about dependencies, like that one could just say: (Package named: 'NativeBoost-Core') unload. i'm not blaming anyone, i just think that instead of investing effort into creating manually crafted things each time, it would be wiser to invest effort into creating things which will do it automatically freeing us from such boring and counterproductive tasks once and for all. > However the resultant image is quite dirty then (look at obsoleteClasses) > and OSEnvironment uses NB to get some information so such image rises > startup errors. Can we look at these issues, Igro? > > sure.. but it would be much less work if people would care about it from the very starting :/ >> >>> I want to ask if we want to be able to do that. >>> >> >> Definitely. >> >> >>> I know that in future they should play more important role but they >>> support only one architecture so it seems reasonable to me to do not >>> declare them currently as kernel packages (only the default ones) and have >>> a configuration with an ability to unload them. >>> >>> I am not sure, to me FFI is a core feature which you would want to have >> in the system. >> Which makes me think it should belong to if not kernel, but to some basic >> set of packages available in system. >> > > If we can remove it, we should keep it removeable and do it on CI. It's > not about minimalism but about modular system and well defined > dependencies. Beause if some patch that for example uses NB for the default > way to set environment variables breaks the CI job and the patch is > automatically rejected, then the author will maybe start to thing about > dependencies :-) > > yes. And you don't have to convince me why modularity is important and has value :) > -- Pavel > > -- Best regards, Igor Stasenko.

Jan. 10, 2014

Re: [Pharo-dev] NativeBoost unloading?

by Pavel Krivanek

'Athens-PangoCairo', of course 2014/1/10 Pavel Krivanek <pavel.krivanek(a)gmail.com> > > 2014/1/10 Igor Stasenko <siguctua(a)gmail.com> > >> >> On 10 January 2014 11:48, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: >> >>> NativeBoost and AsmJit are quite problematic to unload. >>> >> >> problematic, why? >> > > with the right oder it's doable: > > | remove | > remove := #('Athens-Cairo' 'PangoCairo' 'NativeBoost-Tests' > 'NativeBoost-Examples' 'NativeBoost-Unix' 'NativeBoost-Win32' > 'NativeBoost-Mac' 'NativeBoost-Core' 'NativeBoost-Pools' 'AsmJit-Tests' > 'AsmJit-StackManagement' 'AsmJit-Operands' 'AsmJit-x86' 'AsmJit-Extension' > 'AsmJit-Instructions' 'AsmJit-Core'). > > remove do: [ :packageName | > (MCWorkingCopy forPackage: (MCPackage named: packageName)) unload. ]. > > However the resultant image is quite dirty then (look at obsoleteClasses) > and OSEnvironment uses NB to get some information so such image rises > startup errors. Can we look at these issues, Igro? > > >> >>> I want to ask if we want to be able to do that. >>> >> >> Definitely. >> >> >>> I know that in future they should play more important role but they >>> support only one architecture so it seems reasonable to me to do not >>> declare them currently as kernel packages (only the default ones) and have >>> a configuration with an ability to unload them. >>> >>> I am not sure, to me FFI is a core feature which you would want to have >> in the system. >> Which makes me think it should belong to if not kernel, but to some basic >> set of packages available in system. >> > > If we can remove it, we should keep it removeable and do it on CI. It's > not about minimalism but about modular system and well defined > dependencies. Beause if some patch that for example uses NB for the default > way to set environment variables breaks the CI job and the patch is > automatically rejected, then the author will maybe start to thing about > dependencies :-) > > -- Pavel > > >> >> > Cheers, >>> -- Pavel >>> >>> >>> >> >> >> -- >> Best regards, >> Igor Stasenko. >> > >

Jan. 10, 2014

Re: [Pharo-dev] Two videos to explain what we do when integrating a fix.

by Sven Van Caekenberghe

On 07 Jan 2014, at 10:57, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > Thanks, Stef, I will have a look in the coming days. > Now I wonât have many excuses not to try ;-) And I did, and it worked ! #30683 Thanks for all the help, the screencasts really helped to increase my confidence, the git and CI integration is really seriously impressive. > On 06 Jan 2014, at 16:18, StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> wrote: > >> Hi guys >> >> I produced two videos to show how simple is an integration now (It could be better see below). >> This can influence some of you to help us: sven, ben, igor :)? >> >> First one: install some scripts >> http://stephane.ducasse.free.fr/Videos/PharoIntegration/DownloadingScripts.… >> >> Second one >> http://stephane.ducasse.free.fr/Videos/PharoIntegration/integratingAChange.… >> >> ./prepare >> start menu >> merge 9look at the fixâ¦.) >> freeze menu >> publish menu >> ./publish >> >> I do not think that Monticello is the best tool for managing our changes and code (and I asked money in the past to get an engineer but it was refused and I spent the holiday building a new case to ask money to pay an engineer to >> get a real integration with Git) but for now this is what we have and it is working. I do not want that end users to get expose to >> git on the command-line with different platforms. We should keep the simplicity of Pharo. >> >> Stef >> >> >

Jan. 10, 2014

Re: [Pharo-dev] NativeBoost unloading?

by Pavel Krivanek

2014/1/10 Igor Stasenko <siguctua(a)gmail.com> > > On 10 January 2014 11:48, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > >> NativeBoost and AsmJit are quite problematic to unload. >> > > problematic, why? > with the right oder it's doable: | remove | remove := #('Athens-Cairo' 'PangoCairo' 'NativeBoost-Tests' 'NativeBoost-Examples' 'NativeBoost-Unix' 'NativeBoost-Win32' 'NativeBoost-Mac' 'NativeBoost-Core' 'NativeBoost-Pools' 'AsmJit-Tests' 'AsmJit-StackManagement' 'AsmJit-Operands' 'AsmJit-x86' 'AsmJit-Extension' 'AsmJit-Instructions' 'AsmJit-Core'). remove do: [ :packageName | (MCWorkingCopy forPackage: (MCPackage named: packageName)) unload. ]. However the resultant image is quite dirty then (look at obsoleteClasses) and OSEnvironment uses NB to get some information so such image rises startup errors. Can we look at these issues, Igro? > >> I want to ask if we want to be able to do that. >> > > Definitely. > > >> I know that in future they should play more important role but they >> support only one architecture so it seems reasonable to me to do not >> declare them currently as kernel packages (only the default ones) and have >> a configuration with an ability to unload them. >> >> I am not sure, to me FFI is a core feature which you would want to have > in the system. > Which makes me think it should belong to if not kernel, but to some basic > set of packages available in system. > If we can remove it, we should keep it removeable and do it on CI. It's not about minimalism but about modular system and well defined dependencies. Beause if some patch that for example uses NB for the default way to set environment variables breaks the CI job and the patch is automatically rejected, then the author will maybe start to thing about dependencies :-) -- Pavel > > Cheers, >> -- Pavel >> >> >> > > > -- > Best regards, > Igor Stasenko. >

Jan. 10, 2014

Re: [Pharo-dev] Punishment as an educational method

by Sergi Reyner

2014/1/10 Sebastian Sastre <sebastian(a)flowingconcept.com> > guys this discussion is heading towards a non fruitful direction > > Let's remember why are we here? > > *"The purpose of the Smalltalk project is to provide computer support for > the creative spirit in everyone."* ~ D.H. Ingalls > > Do you know what are the psychological consequences of punishment feedback > on creativity? > As much as people try to turn the issue into what itÂ´s not, the debate seems to boil down to a two-line dialog for me: - "Give me some way to discard changes without a confirmation dialog so I can work as I like, *following my creative spirit*, even if itÂ´s not the default" - "No" I tend to have such uncomplicated views on stuff :) Cheers, Sergi

Jan. 10, 2014

[pharo-project/pharo-core] 8e3f31: 30683

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 8e3f31139722d0049780fe83f3687165e734bd0a https://github.com/pharo-project/pharo-core/commit/8e3f31139722d0049780fe83… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2014-01-10 (Fri, 10 Jan 2014) Changed paths: M Kernel.package/DateAndTime.class/README.md A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script336.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30683.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30683 12611 Update the DateAndTime class comment a bit https://pharo.fogbugz.com/f/cases/12611 http://files.pharo.org/image/30/30683.zip

Jan. 10, 2014

[pharo-project/pharo-core]

by GitHub

Branch: refs/tags/30683 Home: https://github.com/pharo-project/pharo-core

Jan. 10, 2014

Re: [Pharo-dev] Pharo3 build is green!

by Sebastian Sastre

Thanks for the announce and the great work I'm going to create an airflowing worker based on this and set in on a staged account for testing. I'll let you know any insight coming from it Again, thank you very much to all for this sebastian o/ On Jan 9, 2014, at 6:02 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > FInallyâ¦ a lot of work went into this, and I thank everyone who helped! > > We are now running 34134 (together) for the 3 architectures... > <Green.png>

Jan. 10, 2014

Re: [Pharo-dev] TDD in Core

by Benjamin

Thanks for sharing the experience :) It sounds true, and I hope we will manage to have some good doc for Spec and that the code will reach a good quality level :) Ben On 09 Jan 2014, at 14:44, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > One thing I have learned (about myself) is this: first you write a cool piece of library/framework/tool/... and you make it as good and as clean as possible (first iteration). > > When you write unit tests (which you should do during development, let's leave in the middle whether that should be before or after ;-), your code will improve (a lot) because you have to make things cleanly testable (which can be hard). Quality improves. > > Then you write methods and class comments (again, before or after) and you realise that thing are hard to explain which will lead you to refactoring, renaming, cleaning and adding missing pieces. Quality improves. > > Finally, you (try) to write the high level overview document. You want to prove how good your stuff is, you want to have nice, clean examples. Again you will change stuff because of what you learn trying to explain yourself. Quality improves. > > After to you publish, feedback and contributions come in. Quality improves. > > Do a couple of these cycles. Quality goes through the roof ;-) > > It sounds harder than it is, but it is worth it. > > And Spec already has lots of the required pieces, I think it just needs some polishing. > > On 09 Jan 2014, at 18:28, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: > >> As usual the problem is that it takes time :) >> (and also that I am a newbie when it comes to write :P) >> >> Ben >> >> On 09 Jan 2014, at 14:26, Sven Van Caekenberghe <sven(a)stfx.eu> wrote: >> >>> >>> On 09 Jan 2014, at 18:14, Benjamin <benjamin.vanryseghem.pharo(a)gmail.com> wrote: >>> >>>> For Spec, I actually sent a mail in the mailing list when integrated explaining how to move to the new version :) >>>> But indeed, not enough documentation about it is present, this is why I am currently spending time writing some :P >>>> (but you already know that :P) >>>> >>>> I think the overall remark is good :) >>>> We should not integrate things in Pharo if they are under tested (Spec included). >>>> >>>> I think that the next month will be spent on writing more tests or Spec >>>> >>>> Ben >>> >>> Yes, some good, high-level, independent docs (like a book chapter) combined with unit tests will improve things a lot. And there are already existing examples. >>> >>> We'll get there, I am sure. >>> >>> Thanks for all the efforts. >>> >>> Sven >> > >

Jan. 10, 2014

Re: [Pharo-dev] Punishment as an educational method

by Sebastian Sastre

guys this discussion is heading towards a non fruitful direction Let's remember why are we here? "The purpose of the Smalltalk project is to provide computer support for the creative spirit in everyone." ~ D.H. Ingalls Do you know what are the psychological consequences of punishment feedback on creativity? Or you don't even admit psychology as science? The instant feature feedback is the ultimate education by experimentation tool. If we are not discussing that, which I think we are not, then what's in play here? People is not buying the screw your code if you did the wrong click idea for the UI I have no problem if that can be as a setting buried in some place interested geeks will surely find Anything beside that IMHO is way off topic so why take our precious time trying to discuss things we aren't basing on data and serious experiments? (experiments that should be validated by cognitive scientist, anyone in the room? or, the poor's man solution: usability tests, which I've already suggested,* any results on those?) sebastian o/ *http://blip.tv/business-of-software/steve-krug-on-the-least-you-can-do-about-usability-1566021 On Jan 10, 2014, at 9:49 AM, Igor Stasenko <siguctua(a)gmail.com> wrote: > > > > On 10 January 2014 11:37, kilon alios <kilon.alios(a)gmail.com> wrote: > You know what is bad ? Simplifiications and Generalisations. > > The only thing that is predictable about humans is their unpredictability. Education is an extremely complex subject because humans are extremely complex in the way they think and feel. For example I have a phobia for dentists, yet never in my life I felt extreme pain on the chair of a dentists. I had almost panic attacks because I had to remove an impacted second horizontal wisdom tooth, took me 6 months to find the courage to do it and the experience was more than ok. On the other hand I removed a cyst on my throat , the size of a small marble ball, the local aneasthesia did not work and i felt load of pain (felt every cut by the surgeon for 45 minutes) yet , I was ok with it and never worried or afraid at all. > > Educations is based on this extremely complex organ called "brain", that has scientists baffled about the exact way it works even with todays technology. I also read psychology from time to time, I am especially interested on cognitive psychology and as you would expect its an extremely complex science with tons of experimental data and theories that barely touch human thinking and feeling. > > The way I see it education is still in stone age, its clear that educational systems around the world fail spectacularly into motivating people to learn and find their true calling. As it is education is not able to treat people taking into their account their differences in the way they think and feel. > > But I would not let my daughter touch fire to learn why it should not touch fire, I would rather sit down and explain her and motivate her into thinking logically. > > Keep trying. But when you find that your daughter laughs at you as someone dumb and cheating behind your back when you can't see her, you'll going to remember this discussion. > Also, teach her that any logical conclusions which not backed by physical evidence worth nothing and having equal chance to be true of false. > You cannot earn trust by simply saying: listen to what i saying because i know. > Going this way is asking for disaster. > You can put soft pillows everywhere in your house, so in case if someone will fall, he won't be hurt.. but the problem is outside: there is no soft pillows outside, and raising children in such soft-pillowed environment is very bad, because then they are completely unprepared for real life, which is harsh, crude and violent at times. > > You know, sometimes you have to fall on something hard, to realize that you have to be careful. > Again kids: this happens a lot to kids once they learn how to stand and then walk and then run.. they fall constantly, hurt themselves, and this is the way they learn what moves are safe and what could lead to bad effects. > And again, you can spend years explaining to your kid how to walk, how to move legs and how to run.. > So, good luck with teaching kid how to walk, without letting kid fall and hurt oneself. > > Or else she may end up not having more than the intelligent of a worm. Cause even worm if put into a electrified labyrinth and each time it passes through a corridor is "punished" with touching the electrical fence , it learns which is the correct way to go. Is this how you want to treat people and education ? > > > Again extreme side of spectrum. Haven't you thought that maybe it is because worms are so primitive, that this is the only way to "teach" them or stimulate their "intelligence"? > While, in case of humans, there's a lot more ways to teach. > > -- > Best regards, > Igor Stasenko.

Jan. 10, 2014