- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Don't want to see a particular notification

by Norbert Hartl

Am 21.07.2013 um 10:32 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > > On Jul 21, 2013, at 10:20 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > >> >> >> Am 21.07.2013 um 10:16 schrieb Marcus Denker <marcus.denker(a)inria.fr>: >> >>> >>> On Jul 21, 2013, at 10:05 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: >>> >>>> Hi, >>>> >>>> in SmalltalkImage>>checkAndOpenSourcesAndChanges, there is some code >>>> that looks like this: >>>> >>>> [...] >>>> changes isReadOnly >>>> ifTrue: [ self inform: 'Pharo cannot write to the >>>> changes file ...' ]. >>>> [...] >>>> >>>> This code raises a warning if the changes file can't be written to. In >>>> the PharoLauncher case, the image and changes file won't be writable >>>> and it is ok (they will be in a place like /usr/lib). I certainly >>>> don't want my users to see this warning. >>>> >>>> What can I do please? >>>> >>> >>> We need to get rid of .changes and .sourcesâ¦ it will solve all kinds of problems. >>> >> What will be the replacement? >> > > -> transaction log attached to he end of the running image file > Ok, sounds reasonable on the one hand (getting rid of an additional file) and dangerous on the other hand (on image write the transaction log needs to be read/written/moved making it possible to loose image and transaction log. Think about a "disk full" scenario). How is this covered? > -> accepted methods kept in image history until next commit to the source repo > Great. Everyone can have a ImmediateCommitStrategy so no reason to complain, right? > -> sources in image. First compresses text with a shared compression dictionary, > later a high-level representation of code that superseded the AST, text and bytecode. > That is really cool. There is no reason to have sources separate until you treat it like text you basicall don't care about. I'm curious with what you'll come up with regarding the thing that supersedes ast, text and bytecode. And especially if the visual syntax can still be the same as it is now. As you know I would be a fan of something that would keep the smalltalk syntax (meaning visual characters) the same but adds visual things (colors, icons, type setting) to indicate the presence of meta data. Underneath there be something that can transport the code with an extended source format to another image. Cool times are these. > Yes, and I know that everyone things that this is wrong. And I don't care :-) > Come on. Things aren't that bad. Just imagine that all of the people that aren't complaining do agree or don't care about. And that's a way bigger number. I personally like those steps even if it means we are loosing a lot of tools and frameworks out there (And there aren't that many) Norbert

July 21, 2013

ESUG 2013 registration is open

by stephane ducasse

Hi guys Sorry for the delay, the registration for the 2013 ESUG conference is now open. Pay attention that the early bird registration is until 10 th of August. http://www.esug.org/wiki/pier/Conferences/2013/Conference-Registration In addition this year, there will be no warranty for social event or goody for people registrering on site. Stef and the ESUG board

July 21, 2013

ESUG 2013 registration is open

by StÃ©phane Ducasse

Hi guys Sorry for the delay, the registration for the 2013 ESUG conference is now open. Pay attention that the early bird registration is until 10 th of August. http://www.esug.org/wiki/pier/Conferences/2013/Conference-Registration In addition this year, there will be no warranty for social event or goody for people registrering on site. Stef and the ESUG board

July 21, 2013

Re: [Pharo-dev] Don't want to see a particular notification

by Marcus Denker

On Jul 21, 2013, at 10:20 AM, Norbert Hartl <norbert(a)hartl.name> wrote: > > > Am 21.07.2013 um 10:16 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > >> >> On Jul 21, 2013, at 10:05 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: >> >>> Hi, >>> >>> in SmalltalkImage>>checkAndOpenSourcesAndChanges, there is some code >>> that looks like this: >>> >>> [...] >>> changes isReadOnly >>> ifTrue: [ self inform: 'Pharo cannot write to the >>> changes file ...' ]. >>> [...] >>> >>> This code raises a warning if the changes file can't be written to. In >>> the PharoLauncher case, the image and changes file won't be writable >>> and it is ok (they will be in a place like /usr/lib). I certainly >>> don't want my users to see this warning. >>> >>> What can I do please? >>> >> >> We need to get rid of .changes and .sourcesâ¦ it will solve all kinds of problems. >> > What will be the replacement? > -> transaction log attached to he end of the running image file -> accepted methods kept in image history until next commit to the source repo -> sources in image. First compresses text with a shared compression dictionary, later a high-level representation of code that superseded the AST, text and bytecode. Yes, and I know that everyone things that this is wrong. And I don't care :-) Marcus

July 21, 2013

Re: [Pharo-dev] Don't want to see a particular notification

by Norbert Hartl

Am 21.07.2013 um 10:16 schrieb Marcus Denker <marcus.denker(a)inria.fr>: > > On Jul 21, 2013, at 10:05 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > >> Hi, >> >> in SmalltalkImage>>checkAndOpenSourcesAndChanges, there is some code >> that looks like this: >> >> [...] >> changes isReadOnly >> ifTrue: [ self inform: 'Pharo cannot write to the >> changes file ...' ]. >> [...] >> >> This code raises a warning if the changes file can't be written to. In >> the PharoLauncher case, the image and changes file won't be writable >> and it is ok (they will be in a place like /usr/lib). I certainly >> don't want my users to see this warning. >> >> What can I do please? >> > > We need to get rid of .changes and .sourcesâ¦ it will solve all kinds of problems. > What will be the replacement? Norbert

July 21, 2013

Re: [Pharo-dev] Don't want to see a particular notification

by Norbert Hartl

How about SmalltalkImage checkChangesFileAvailability: false. ? Norbert Am 21.07.2013 um 10:04 schrieb Damien Cassou <damien.cassou(a)gmail.com>: > Hi, > > in SmalltalkImage>>checkAndOpenSourcesAndChanges, there is some code > that looks like this: > > [...] > changes isReadOnly > ifTrue: [ self inform: 'Pharo cannot write to the > changes file ...' ]. > [...] > > This code raises a warning if the changes file can't be written to. In > the PharoLauncher case, the image and changes file won't be writable > and it is ok (they will be in a place like /usr/lib). I certainly > don't want my users to see this warning. > > What can I do please? > > -- > Damien Cassou > http://damiencassou.seasidehosting.st > > "Success is the ability to go from one failure to another without > losing enthusiasm." > Winston Churchill >

July 21, 2013

Re: [Pharo-dev] Don't want to see a particular notification

by Marcus Denker

On Jul 21, 2013, at 10:05 AM, Damien Cassou <damien.cassou(a)gmail.com> wrote: > Hi, > > in SmalltalkImage>>checkAndOpenSourcesAndChanges, there is some code > that looks like this: > > [...] > changes isReadOnly > ifTrue: [ self inform: 'Pharo cannot write to the > changes file ...' ]. > [...] > > This code raises a warning if the changes file can't be written to. In > the PharoLauncher case, the image and changes file won't be writable > and it is ok (they will be in a place like /usr/lib). I certainly > don't want my users to see this warning. > > What can I do please? > We need to get rid of .changes and .sourcesâ¦ it will solve all kinds of problems. Marcus

July 21, 2013

Don't want to see a particular notification

by Damien Cassou

Hi, in SmalltalkImage>>checkAndOpenSourcesAndChanges, there is some code that looks like this: [...] changes isReadOnly ifTrue: [ self inform: 'Pharo cannot write to the changes file ...' ]. [...] This code raises a warning if the changes file can't be written to. In the PharoLauncher case, the image and changes file won't be writable and it is ok (they will be in a place like /usr/lib). I certainly don't want my users to see this warning. What can I do please? -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." Winston Churchill

July 21, 2013

[update 3.0] #30288

by Marcus Denker

30288 ----- 11201 InvalidArgument + a few exceptions comments https://pharo.fogbugz.com/f/cases/11201 11163 TestCase class>run convenience method https://pharo.fogbugz.com/f/cases/11163 Diff information: http://smalltalkhub.com/mc/Pharo/Pharo30/main/SUnit-Core-MarcusDenker.81.di… http://smalltalkhub.com/mc/Pharo/Pharo30/main/Kernel-MarcusDenker.1529.diff

July 21, 2013

Re: [Pharo-dev] About abuse of inheritance

by Tudor Girba

Certainly :) Doru On Sat, Jul 20, 2013 at 1:48 PM, Camillo Bruni <camillobruni(a)gmail.com>wrote: > How about statefull Traits? > http://scg.unibe.ch/archive/papers/Berg07aStatefulTraits.pdf > > > On 2013-07-20, at 12:48, Denis Kudriashov <dionisiydk(a)gmail.com> wrote: > > Hi > > > > 2013/7/19 Igor Stasenko <siguctua(a)gmail.com> > > > >> So, on your place, if you really need a lot of classes with announcer > >> capabilities, you can do it like that: > >> > >> Object subclass: #ObjectWithAnnouncer > >> instvars: 'announcer' > >> > >> > > ObjectWithAnnouncer is exactly what I think about Announcer. I just need > > class which makes my objects events sources. And I'm wondering why > > Announcer is bad for this? > > Just look at Announcer definition: > > > > Object subclass: #Announcer > > > > instanceVariableNames: 'registry' > > > > classVariableNames: '' > > > > poolDictionaries: '' > > > > category: 'Announcements-Core' > > > > > > "registry" variable is instance of SubscriptionsRegistry which actually > > implements all announcements logic. Announcer just adds convenient public > > api to events subscriptions and delivering. No complex logic. No actual > > knowledge about how announcements work. > > And your argument "why you subclass from Announcer" looks to me like why > > you subclass from SubscriptionsRegistry. But I'm not. Nobody doing it. > > So i'm not understand why you want another wrapper around Announcer. > > > > (To me "subscriptions" is better name then "registry". And I prefer > > composition than inheritance too). > > > > > > > >> then may implement same protocol as in Announcer in it, which will > >> simply delegate to announcer ivar. > >> And i bet, you don't want to expose full Announcer protocol there, > >> while probably you may want to implement some convenience protocols, > >> which Announcer lacking. > >> > >> So, at the end by subclassing from ObjectWithAnnouncer you will be > >> reusing its capabilities in each and every subclass of it, but by > >> delegating real job, you are free from worrying about dealing with > >> implementation detail and exposing unwanted state/protocols to its > >> users. > >> > >> Another aspect of it, is when i see: > >> > >> ObjectWithAnnouncer subclass: #MyDomainObject > >> > >> it tells me, aha.. so some (at least this one) of his domain objects > >> having announcers, > >> and the valid protocols is defined in ObjectWithAnnouncer. > >> > >> but when i see > >> > >> Announcer subclass: #MyDomainObject > >> > >> i starting to be uncertain: is Announcer private there or public? > >> can i send messages like #basicSubscribe: to your domain object and > expect > >> that > >> it will be handled correctly? Or do i allowed to subscribe directly at > >> all, because maybe > >> domain object has some specific protocol(s) and ways to do that.. > >> Every such question and uncertainty for coder means more time, more > >> errors, and less productivity. > >> > >> > >> -- > >> Best regards, > >> Igor Stasenko. > >> > >> > > > -- www.tudorgirba.com "Every thing has its own flow"

July 20, 2013