December 2013 - Pharo-dev - lists.pharo.org

[pharo-project/pharo-core]

by GitHub

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

Dec. 5, 2013

[pharo-project/pharo-core] 2a2066: 30622

by GitHub

Branch: refs/heads/3.0 Home: https://github.com/pharo-project/pharo-core Commit: 2a2066a1c5cc797ddd25e470115ab7ed577d3afd https://github.com/pharo-project/pharo-core/commit/2a2066a1c5cc797ddd25e470… Author: Jenkins Build Server <board(a)pharo-project.org> Date: 2013-12-04 (Wed, 04 Dec 2013) Changed paths: A Komitter.package/CredentialEditor.class/README.md A Komitter.package/CredentialEditor.class/class/specs/defaultSpec.st A Komitter.package/CredentialEditor.class/definition.st A Komitter.package/CredentialEditor.class/instance/accessing/password.st A Komitter.package/CredentialEditor.class/instance/accessing/passwordLabel.st A Komitter.package/CredentialEditor.class/instance/accessing/showPasswordWidget.st A Komitter.package/CredentialEditor.class/instance/accessing/username.st A Komitter.package/CredentialEditor.class/instance/accessing/usernameLabel.st A Komitter.package/CredentialEditor.class/instance/initialize-release/initializeDialogWindow_.st A Komitter.package/CredentialEditor.class/instance/initialize-release/initializePresenter.st A Komitter.package/CredentialEditor.class/instance/initialize-release/initializeWidgets.st A Komitter.package/CredentialEditor.class/instance/protocol/getPassword.st A Komitter.package/CredentialEditor.class/instance/protocol/getUsername.st A Komitter.package/CredentialEditor.class/instance/protocol/initialExtent.st A Komitter.package/CredentialEditor.class/instance/protocol/setPassword_.st A Komitter.package/CredentialEditor.class/instance/protocol/setUsername_.st A Komitter.package/CredentialEditor.class/instance/protocol/title.st A Komitter.package/KomitRemote.class/instance/as yet unclassified /password.st A Komitter.package/KomitRemote.class/instance/protocol/password_.st A Komitter.package/KomitRemote.class/instance/protocol/username.st A Komitter.package/KomitRemote.class/instance/protocol/username_.st A Komitter.package/Komitter.class/class/protocol/openAndCommitToMonticello.st R Komitter.package/Komitter.class/class/world menu/finderMenuOn_.st A Komitter.package/Komitter.class/class/world menu/initialize.st A Komitter.package/Komitter.class/class/world menu/komitterMenuOn_.st M Komitter.package/KomitterUI.class/instance/initialization/initializeLatelyPresenter.st M Komitter.package/KomitterUI.class/instance/private/openRemoteManager.st A Komitter.package/RemotesManager.class/class/icons/editRemoteIcon.st A Komitter.package/RemotesManager.class/class/private-icons/editRemoteIconData.st M Komitter.package/RemotesManager.class/class/specs/defaultSpec.st M Komitter.package/RemotesManager.class/definition.st R Komitter.package/RemotesManager.class/instance/accessing/addRemote.st A Komitter.package/RemotesManager.class/instance/accessing/addRemoteWidget.st A Komitter.package/RemotesManager.class/instance/accessing/editRemoteWidget.st R Komitter.package/RemotesManager.class/instance/accessing/removeRemote.st A Komitter.package/RemotesManager.class/instance/accessing/removeRemoteWidget.st R Komitter.package/RemotesManager.class/instance/initialization/buildRoots.st A Komitter.package/RemotesManager.class/instance/initialization/initializeDialogWindow_.st M Komitter.package/RemotesManager.class/instance/initialization/initializePresenter.st M Komitter.package/RemotesManager.class/instance/initialization/initializeWidgets.st A Komitter.package/RemotesManager.class/instance/private-icons/editRemoteIcon.st A Komitter.package/RemotesManager.class/instance/private/addRemote.st R Komitter.package/RemotesManager.class/instance/private/addRepository.st A Komitter.package/RemotesManager.class/instance/private/buildRoots.st A Komitter.package/RemotesManager.class/instance/private/editRemote.st A Komitter.package/RemotesManager.class/instance/private/newRemote.st R Komitter.package/RemotesManager.class/instance/private/newRepository.st A Komitter.package/RemotesManager.class/instance/private/removeRemote.st R Komitter.package/RemotesManager.class/instance/private/removeRepository.st M Nautilus.package/MultipleMethodsEditor.class/instance/updating/updateLayoutForSingleWithButtons.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - scripts/script277.st A ScriptLoader30.package/ScriptLoader.class/instance/pharo - updates/update30622.st M ScriptLoader30.package/ScriptLoader.class/instance/public/commentForCurrentUpdate.st Log Message: ----------- 30622 12334 Nautilus codepane hides first lines if pin is set https://pharo.fogbugz.com/f/cases/12334 12337 Install global shortcut https://pharo.fogbugz.com/f/cases/12337 12333 Add a button to edit a remote in RemotesManager https://pharo.fogbugz.com/f/cases/12333 http://files.pharo.org/image/30/30622.zip

Dec. 5, 2013

Re: [Pharo-dev] Opal hook?

by StÃ©phane Ducasse

On Dec 4, 2013, at 10:02 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > It didn't halt on your machine because you didn't copy and paste the code that halts (i guess I wrote too much code in the mail so it was not clear). You copied the code that I explicitly said that doesn't halt because the error is raised at compilation time. I saw it do not worry. I was just shocked by the state of the exceptions. > > This code halts (copy, paste and run it you will see): > > > [ OpalCompiler new evaluate: 'AnUnknownClass subclass: #Adaptor1Example > instanceVariableNames: ''customers accountID address name phoneNumber'' > classVariableNames: '''' > poolDictionaries: '''' > category: ''Examples-Cookbook''' ] on: OCSemanticWarning do: [ :e | e halt ] > > > We can discuss this another day when you have time because seemingly my mail was not clear (you said you couldn't trap the semantic warning). Now I'm really sick today so we can discuss friday or next week. rest well > > > > 2013/12/4 StÃ©phane Ducasse <stephane.ducasse(a)inria.fr> > > >> Ok I will check something on UndefinedObject to start with. > >> Then it would be fun to prototype a kind of strategy hiearchy on the side (extracted from also) behavior of OCSemanticsError > >> It was nice to see it and since now I'm ok to have a look at the compiler code it was interesting. > >> > > > > The current design is motivated mostly by backward compatibility, not anything else. > > I see :) > I would really to see an headless, interactive and scriptable scenarios to be exercised. So this is good it will get better :) > Stef >

Dec. 5, 2013

Re: [Pharo-dev] [Nautilus] Selecting package

by StÃ©phane Ducasse

> Hi Stef, > > I spoke with Esteban before, however thanks for the clarification. > > IMHO however the current structure is confusing, and names are misleading. The thing about packages, categories, namespaces and what not has always been not perfect for me, nor in Pharo nor in many other PLs. > > The way I would have done it, conceptually, independently of Nautilus, Monticello and whatever else is the following: > > A package is a container used to structure a project, it contains > - zero or more classes > - zero or more other packages this is the world of "bisounours" welcome to reality. > This model would be damn simple, and consistent and not covering what we want :) > and you should not explicitly think about how to structure your things.. > I can create a package âDFlowâ put some classes, then I create another package 'DFlow-Coreâ which *automatically* goes into the âDFlowâ package because it starts with the same prefix plus the dash, we do not want to rely on naming conventions. Now this has been discussed during a couple of years. so look for it and esteban spent 5 months on it so do you think that it was that simple? > which is somewhat our convention, right? And however we can think of mechanisms to cope with other kind of automatic sub-packaging and/or manual removal (in case our heuristics fail). I can think to a lot of nice solutions but after you should have solutions - scale - migrate - fit people practices > > For me having packages, groups, tags, and categories is too much. We are killing categories and I would have removed it completely (not having tags) but people and practice showed that they were needed Then groups is just so handy I use that all the time. Then I do not understand why you bother. The point is that each of these objects should reply polymorphically to the same message probably allClasses, extensions, â¦ if this is not the case then this is also easy we should add these messages. If you do not have specific entities you are forced to have conditionals and it starts to get ugy and not modular so I do not see your problems. OO design is your friend but it requires time to deeply understand it.

Dec. 5, 2013

Re: [Pharo-dev] 12259: FileSystem memory reads writesusing a binary stream by default

by StÃ©phane Ducasse

On Dec 5, 2013, at 7:48 AM, Max Leske <maxleske(a)gmail.com> wrote: > Thanks for the input. > > The problem with ReadStream and WriteStream is that they (at least in 2.0 and 3.0) never supported switching in the first place. #binary and #ascii simply answer self. That means the collection the stream operates on predetermines the output. Iâve noticed a couple of different approaches to solving this problem in the way that streams are used throughout the image and I want to make a list of those to see if thereâs some kind of pattern that maybe leads to an acceptable version with little changes as opposed to an optimal version where we have to change a lot of the implemenation details of streams. thanks such analysis is indeed important. > > Cheers, > Max > > > On 04.12.2013, at 19:45, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> Here would be the Xtream way IMHO: >> 1) At the end, the file should be handled as binary. >> 2) A facade BivalentReadStream (and BivalentWriteStream) would be created, able to switch encoding >> 3) The implementation would be to wrap either directly over the binary stream, or indirectly over an encoded stream which wraps other the binary stream. >> 4) For write, the facade should just ensure that buffers (if any) are properly flushed, and then just delegate to specialized wrapped streams. >> 5) For read, it might be a bit more involved if some buffer were used in intermediate wrappers, because they should push back the excess bytes read and restore the state of lower level binary stream... >> In all case, all should happen thru delegation and the facade should be rather dumb. >> >> >> 2013/12/4 Sven Van Caekenberghe <sven(a)stfx.eu> >> >> On 04 Dec 2013, at 13:14, Max Leske <maxleske(a)gmail.com> wrote: >> >> > Let me see what I can come up with. >> >> To be somewhat compatible with existing streams, your memory stream should have the concept of âi am binary or textualâ and be able to switch in-place between these two states (#binary, #ascii). Depending on its state it should then return bytes or characters (or collections thereof). Have a look at ZnLimitedReadStream>>#next and/or ZnBivalentWriteStream>>#nextPut: >> >> To be 100% correct, encoding should be selectable. But maybe a default to utf-8 would be enough. You could have a look at ZnCharacter[Read|Write]Stream for inspiration. >> >> My 2c. >> >> > On 03.12.2013, at 19:36, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> > >> >> Thanks Max for the report. Do you have an idea on how we could solve the problem ? The previous behaviour was not acceptable either because the streams that came out of a memory filesystem were the only ones with binary content >> >> >> >> On Dec 3, 2013 5:35 PM, "Max Leske" <maxleske(a)gmail.com> wrote: >> >> Damien, Marcus >> >> >> >> this change breaks a lot of things in FileSystem-Git. I donât disagree with the idea that reading characters should be default (one could argue about itâ¦) but your change makes it IMPOSSIBLE to read bytes because unprintable characters are discarded! So if my ByteArray is a NULL terminated string, for instance, I can not check for the NULL termination anymore. >> >> >> >> Cheers, >> >> Max >> > >> >> >> >

Dec. 5, 2013

Re: [Pharo-dev] Committing slices to Pharo30Inbox still doesn't work for me

by Max Leske

Noted. Thanks Marcus. On 05.12.2013, at 08:10, Marcus Denker <marcus.denker(a)inria.fr> wrote: > It would be nice if someone else but me could do thisâ¦ small things like this can suck away *all* time > if only one person does them. > > (and no, I *never* had problems to submit a sliceâ¦) > > > On 04 Dec 2013, at 20:54, Stephan Eggermont <stephan(a)stack.nl> wrote: > >> Hereâs a new slice, the corresponding packages are in the inbox. >> <SLICE-Issue-12324-There-should-be-no-class-side-implementations-of-packages-except-for-ClassDescription-StephanEggermont.2.mcz> > >

Dec. 5, 2013

Re: [Pharo-dev] Committing slices to Pharo30Inbox still doesn't work for me

by Marcus Denker

It would be nice if someone else but me could do thisâ¦ small things like this can suck away *all* time if only one person does them. (and no, I *never* had problems to submit a sliceâ¦) On 04 Dec 2013, at 20:54, Stephan Eggermont <stephan(a)stack.nl> wrote: > Hereâs a new slice, the corresponding packages are in the inbox. > <SLICE-Issue-12324-There-should-be-no-class-side-implementations-of-packages-except-for-ClassDescription-StephanEggermont.2.mcz>

Dec. 5, 2013

Lectures at Prague

by StÃ©phane Ducasse

Alive and Kicking This presentation will discuss some successes stories around Smalltalk such AMD 64 bits, OOCL (http://www.oocl.com/) MediaGenix (www.mediagenix.tv) LAMRC (http://www.lamrc.com) netstyle.ch or yesplan.be. Then I will talk about Pharo and the recent advances in Pharo 20 and 30 alpha. More importantly I will give an overview of all the partners and shows that Pharo is composed of a really strong community of academic partners, research groups and companies. In addition I will stress that Pharo is YOUR open-source platform and that if you start to consider it as it then suddenly you realise that you want to improve it and that you can get an impact and influence Pharo's future and your future. I will finish by an key example showing the essence of object-oriented programming and prove to the audience that this is because of such example that Pharo is one of the best system to understand deeply object-oriented programming from its roots. Bio: Stephane leads the RMoD (http://rmod.lille.inria.fr) team. He is expert in two domains: object-oriented language design and reengineering. He worked on traits, composable groups of methods, and this work got some impact. Traits have been introduced in AmbiantTalk, and Squeak/Pharo, Perl, PHP and under a variant into Scala, Fortress of SUN Microsystems. He is one of the developer of Pharo http://www.pharo.org/ a new dynamic language used in industry and academia. He is also expert on software quality, program understanding, program visualizations, reengineering and metamodeling. He is one of the developer of Moose, an open-source software analysis platform http://www.moosetechnology.org/. He is working with http://www.synectique.eu/ a company building dedicated tools for advanced software analysis. He wrote several books: Pharo by Example and Deep into Pharo. He is president of ESUG http://www.esug.org Lecture: Prague Monday 9 December at The lecture starts at 4:15pm in the new Czech National Technical Library There will be a workshop wednesday / thursday afternoon Stef

Dec. 5, 2013

Smalltalker meeting at Prague

by StÃ©phane Ducasse

Hi guys I will be at Prague teaching from 9 to 13 december and we can organise a Smalltalker gathering for example after work. Tell me if you are interested. Stef

Dec. 5, 2013

Re: [Pharo-dev] 12259: FileSystem memory reads writesusing a binary stream by default

by Max Leske

Thanks for the input. The problem with ReadStream and WriteStream is that they (at least in 2.0 and 3.0) never supported switching in the first place. #binary and #ascii simply answer self. That means the collection the stream operates on predetermines the output. Iâve noticed a couple of different approaches to solving this problem in the way that streams are used throughout the image and I want to make a list of those to see if thereâs some kind of pattern that maybe leads to an acceptable version with little changes as opposed to an optimal version where we have to change a lot of the implemenation details of streams. Cheers, Max On 04.12.2013, at 19:45, Nicolas Cellier <nicolas.cellier.aka.nice(a)gmail.com> wrote: > Here would be the Xtream way IMHO: > 1) At the end, the file should be handled as binary. > 2) A facade BivalentReadStream (and BivalentWriteStream) would be created, able to switch encoding > 3) The implementation would be to wrap either directly over the binary stream, or indirectly over an encoded stream which wraps other the binary stream. > 4) For write, the facade should just ensure that buffers (if any) are properly flushed, and then just delegate to specialized wrapped streams. > 5) For read, it might be a bit more involved if some buffer were used in intermediate wrappers, because they should push back the excess bytes read and restore the state of lower level binary stream... > In all case, all should happen thru delegation and the facade should be rather dumb. > > > 2013/12/4 Sven Van Caekenberghe <sven(a)stfx.eu> > > On 04 Dec 2013, at 13:14, Max Leske <maxleske(a)gmail.com> wrote: > > > Let me see what I can come up with. > > To be somewhat compatible with existing streams, your memory stream should have the concept of âi am binary or textualâ and be able to switch in-place between these two states (#binary, #ascii). Depending on its state it should then return bytes or characters (or collections thereof). Have a look at ZnLimitedReadStream>>#next and/or ZnBivalentWriteStream>>#nextPut: > > To be 100% correct, encoding should be selectable. But maybe a default to utf-8 would be enough. You could have a look at ZnCharacter[Read|Write]Stream for inspiration. > > My 2c. > > > On 03.12.2013, at 19:36, Damien Cassou <damien.cassou(a)gmail.com> wrote: > > > >> Thanks Max for the report. Do you have an idea on how we could solve the problem ? The previous behaviour was not acceptable either because the streams that came out of a memory filesystem were the only ones with binary content > >> > >> On Dec 3, 2013 5:35 PM, "Max Leske" <maxleske(a)gmail.com> wrote: > >> Damien, Marcus > >> > >> this change breaks a lot of things in FileSystem-Git. I donât disagree with the idea that reading characters should be default (one could argue about itâ¦) but your change makes it IMPOSSIBLE to read bytes because unprintable characters are discarded! So if my ByteArray is a NULL terminated string, for instance, I can not check for the NULL termination anymore. > >> > >> Cheers, > >> Max > > > > >

Dec. 5, 2013