- Pharo-dev - lists.pharo.org

Re: [Pharo-project] KeyChain/UsersManager

by Igor Stasenko

On 15 December 2012 14:16, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > what is the reason for integration of KeyChain/UsersManager to the image? It > created the next kernel dependency. Should it replace Author? Should it be > in the Pharo Kernel? And why there was no mention about it in this mailing > list before? ;-) > Yes, i also would like to hear arguments why we need it. > Cheers, > -- Pavel -- Best regards, Igor Stasenko.

Dec. 15, 2012

Re: [Pharo-project] About (backwards) Compatibility

by H. Hirzel

On 12/15/12, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Janko, > that's already done (since ever), and FD is provided in two different ways: > in the graveyard is the old FD package (loadable into pharo 2.0) > http://smalltalkhub.com/#!/~Pharo/Graveyard20 , and also Camillo made a FD > wrapper to FS... Excellent, where is this FD wrapper to FS of Camillo available? --Hannes > Esteban > > On Dec 15, 2012, at 12:31 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > >> Dne 15. 12. 2012 12:12, piÅ¡e Igor Stasenko: >>> On 15 December 2012 10:27, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: >> >>>> Is there any technical reason that the old FileDirectory stuff doesn't >>>> stay and work in parallel to a new FileSystem? Maybe in some package >>>> marked obsolete. Both use the same plugin and the same primitives, so >>>> where is the problem? >> >>> Yes, there's one big reason: maintainability. And manpower. >>> Who would like to maintain FD? Any takers? >> >> Gain with a (in this case very small) bit of manpower to ease upgrade to >> new FS by providing existing FD for a while outweighs the loss by not >> doing that. As a professional organization providing a professional >> product Pharo should think rather that way. >> >> Janko >> >>> >>>> >>>> I also think that for a professionally viable product a clear migration >>>> path should be provided. Progress yes, but user base must have a >>>> guidance how to slowly migrate to the new functionality. If possible >>>> with some automated procedure to migrate our code. >>>> >>>> In case of FileSystem/FileDirectory, this is certainly quite a big >>>> change and will break a lot of code. Be sure therefore that you guide >>>> us >>>> as much as possible, otherwise there is a danger to loose a lot of user >>>> base behind. >>>> >>> But there is a well-written documentation of FS. >>> I wonder, if there's any documentation for FileDirectory ever existed. >>> >>>> Best regards >>>> Janko >>>> >>>> Dne 15. 12. 2012 08:55, piÅ¡e StÃ©phane Ducasse: >>>>> Chris >>>>> >>>>> Could you give us a break pleaseeeeeee? >>>>> We are spending all our energy to build a better system that other >>>>> people can use to make a living. >>>>> May be we should just create a system for having fun in our teams? >>>>> Because at the end of the day >>>>> we just need to produce ideas and some prototypes (not even build them >>>>> as researchers). >>>>> >>>>> I really think that there are still plenty of places where the system >>>>> is not good. If you disagree then you may want to >>>>> spend more time trying to extend it and build something real with it. >>>>> (Here this is the place where you should react and prove >>>>> to the world that you are a cool entrepreneur) ;D >>>>> >>>>> Now nobody force you to: >>>>> - be in this mailing-list (you are welcome here but can we avoid >>>>> this kind of endless useless discussions) or >>>>> phrase your points with code snippet that can help the system. >>>>> >>>>> - use pharo in fact you are not using it so you are living in an >>>>> happy world. So this is perfect. >>>>> >>>>> Did you read the Pharo motto? >>>>> >>>>> Stef >>>>> >>>>> >>>>> On Dec 14, 2012, at 5:55 PM, Chris Muller wrote: >>>>> >>>>>> I'm tired of talking about this but I just can't let this go.. I >>>>>> don't know if its just romantic, starry-eyed mountain climbers or >>>>>> intentional false-propaganda but... confusion reigns here! :) This >>>>>> example is bunk. >>>>>> >>>>>> Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002 >>>>>> which, for whatever reason, is admittedly not great code but that's >>>>>> not the point -- Sean is trying to use this example to demonstrate >>>>>> how >>>>>> using FileSystem will let you "scale new heights" over FileDirectory. >>>>>> The real equivalent to what Sean wrote is: >>>>>> >>>>>> "FileDirectory" >>>>>> localFileName: aString >>>>>> | file | >>>>>> super localFileName: aString. >>>>>> file := FileDirectory directoryEntryFor: aString. >>>>>> file exists ifFalse: [ ^ self ]. >>>>>> self modifiedAt: file entry modificationTime. >>>>>> >>>>>> "FileSystem" >>>>>> localFileName: aString >>>>>> | file | >>>>>> super localFileName: aString. >>>>>> file := aString asFileName. >>>>>> file exists ifFalse: [ ^ self ]. >>>>>> self modifiedAt: file entry modificationTime. >>>>>> >>>>>> Ahhhh, I've broken all my systems but look how I'm scaling new >>>>>> heights >>>>>> with FileSystem! (not!) >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris >>>>>> <sean(a)clipperadams.com> wrote: >>>>>>> Chris Muller-4 wrote >>>>>>>> While someone in the Pharo >>>>>>>> community said FileSystem over FileDirectory is "huge", I see it as >>>>>>>> an >>>>>>>> incremental API change >>>>>>> >>>>>>> Can you still say that after reading >>>>>>> http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?! >>>>>>> >>>>>>> FileSystem has hugely decremented the number of times I've wanted to >>>>>>> throw >>>>>>> my computer at a wall ;) FileDirectory occurred to me like graffiti >>>>>>> painted >>>>>>> on a great work of art. >>>>>>> >>>>>>> Multiply the above by every dark corner of the system and you have >>>>>>> the >>>>>>> barrier to the next stage of evolution. For myself, every time I've >>>>>>> embarked >>>>>>> on a bold new idea for our IDE, after getting bogged down in a mess >>>>>>> of >>>>>>> objects - like FileDirectory et al, or Paragraph and friends, or >>>>>>> Morphic >>>>>>> layout objects, and on and on - I reached a point where I was not >>>>>>> willing to >>>>>>> put in the tremendous effort required to understand the system (if >>>>>>> even >>>>>>> possible). And because few of the design decisions are documented, I >>>>>>> didn't >>>>>>> know how to clean things without breaking them. So, I gave up and >>>>>>> just went >>>>>>> back to the standard tools. >>>>>>> >>>>>>> I hate to keep repeating myself, but the Pharo manifesto is very >>>>>>> clear, and >>>>>>> makes these types of arguments moot: >>>>>>> - Better for the better >>>>>>> - Beauty to learn from >>>>>>> - Not backward compatible >>>>>>> - Clean, lean and fast >>>>>>> >>>>>>> Cheers, >>>>>>> Sean >>>> >>>> -- >>>> Janko MivÅ¡ek >>>> Aida/Web >>>> Smalltalk Web Application Server >>>> http://www.aidaweb.si >>>> >>> >>> >>> >> >> -- >> Janko MivÅ¡ek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> > >

Dec. 15, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Esteban Lorenzano

Well... the "FD affaire" was discussed in this list like 6 months ago, and that was the path we choose: to put the ObsoletePackages into a "graveyard" repository, so people willing to use it can load and be happy with that. The path you suggested was analyzed (and discarded) at the time because it introduces a certain level of work, even if placed on "obsolete", and we choose to use that effort into make the new things work properly. So, yes... we hear "our customers", but we also have an opinion and we try to do what we think is the better option. To hear does not means "to accept" just like that... Also, are you going to tell me than ask for install a package if you want it is "too much effort" I do want a professional product, but that takes time, effort and some level of acceptance than things needs to be changed to drop old/obsolete stuff... Also, about PR... yes, we all need a better level of communication, but in this case, we actually provided a migration path. And ok, is not what you would do, but now I ask you to hear, and to write the Gofer script into your workspace :) Esteban On Dec 15, 2012, at 1:39 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > > > Dne 15. 12. 2012 12:46, piÅ¡e Igor Stasenko: > >> Hold on.. Since when Pharo project became professional product? >> How much money you and others paying for using it? >> Yes, we position it as a product FOR professionals, >> but does it automatically makes a professional one? >> I don't think so. >> So, why you think that it is correct to put such requirements/expectations it? > > Let me explain what I meant by 'professional product'. Product for > professionals implies the characteristics of professional product. Even > if it is an open source one and partially paid by donations. One of the > main characteristic is a clear path of upgrading to a new version. > Another is a proper 'Customer Relationship Management'. > > BTW, ask Gemstone guys for help here, they are very good in migration > help to the new version and evolution to the new features. Not to > mention their amazing attitude to the customers. > > To conclude, a bit better PR would make wonders here. Sometimes we need > just to listen to our users even that we don't agree with them. Again > one of the characteristics of professional product behavior, like it or > not. > > Janko > > > -- > Janko MivÅ¡ek > Aida/Web > Smalltalk Web Application Server > http://www.aidaweb.si >

Dec. 15, 2012

Re: [Pharo-project] KeyChain/UsersManager

by Esteban Lorenzano

it was in the list of things to integrate :) but we should check to clean the dependence, because is not good. Esteban On Dec 15, 2012, at 2:16 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com> wrote: > Hi, > > what is the reason for integration of KeyChain/UsersManager to the image? It created the next kernel dependency. Should it replace Author? Should it be in the Pharo Kernel? And why there was no mention about it in this mailing list before? ;-) > > Cheers, > -- Pavel

Dec. 15, 2012

Re: [Pharo-project] NBCog broken on 64bit Linux?

by Pavel Krivanek

On Fri, Dec 14, 2012 at 7:58 PM, Pavel Krivanek <pavel.krivanek(a)gmail.com>wrote: > > > On Fri, Dec 14, 2012 at 7:42 PM, Igor Stasenko <siguctua(a)gmail.com> wrote: > >> On 14 December 2012 19:33, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> wrote: >> > >> > >> > On Fri, Dec 14, 2012 at 7:17 PM, Igor Stasenko <siguctua(a)gmail.com> >> wrote: >> >> >> >> On 14 December 2012 19:03, Pavel Krivanek <pavel.krivanek(a)gmail.com> >> >> wrote: >> >> > >> >> > >> >> > On Fri, Dec 14, 2012 at 4:35 PM, Igor Stasenko <siguctua(a)gmail.com> >> >> > wrote: >> >> >> >> >> >> i killled the VM with SIGUSR signal and here the stack: >> >> >> >> >> >> Process 0x77ccf2cc priority 40 >> >> >> 0xbff5517c I [] in Delay>wait 2035889428: a(n) Delay >> >> >> 0xbff551a4 I BlockClosure>ifCurtailed: 2035890000: a(n) BlockClosure >> >> >> 0xbff551c8 I Delay>wait 2035889428: a(n) Delay >> >> >> 0xbff551e8 I TimeStamp class(DateAndTime class)>waitForOffsets >> >> >> 2007868504: a(n) TimeStamp class >> >> >> 0xbff55210 I TimeStamp class(DateAndTime >> >> >> class)>milliSecondsSinceMidnight 2007868504: a(n) TimeStamp class >> >> >> 0xbff55238 I TimeStamp class(DateAndTime class)>now 2007868504: a(n) >> >> >> TimeStamp class >> >> >> 0xbff55260 I TimeStamp class>current 2007868504: a(n) TimeStamp >> class >> >> >> 0xbff55280 I TimeStamp class>now 2007868504: a(n) TimeStamp class >> >> >> 0xbff552a0 I ZnClient>handleResponse 2035558752: a(n) ZnClient >> >> >> 0xbff552c0 I ZnClient>executeWithRedirectsRemaining: 2035558752: >> a(n) >> >> >> ZnClient >> >> >> 0xbff552e4 I [] in ZnClient>executeWithRetriesRemaining: 2035558752: >> >> >> a(n) ZnClient >> >> >> 0xbff55300 M BlockClosure>on:do: 2035590416: a(n) BlockClosure >> >> >> 0xbff55328 I ZnClient>executeWithRetriesRemaining: 2035558752: a(n) >> >> >> ZnClient >> >> >> 0xbff55344 M [] in ZnClient>executeWithTimeout 2035558752: a(n) >> >> >> ZnClient >> >> >> 0xbff55360 M BlockClosure>on:do: 2035590092: a(n) BlockClosure >> >> >> 0xbff55388 I [] in ZnClient>executeWithTimeout 2035558752: a(n) >> >> >> ZnClient >> >> >> 0xbff553ac I [] in ZnClient>withTimeoutDo: 2035558752: a(n) ZnClient >> >> >> 0xbff553d8 I [] in >> ZnConnectionTimeout(DynamicVariable)>value:during: >> >> >> 2007631496: a(n) ZnConnectionTimeout >> >> >> 0xbff553f8 M BlockClosure>ensure: 2035589948: a(n) BlockClosure >> >> >> 0xbff55424 I ZnConnectionTimeout(DynamicVariable)>value:during: >> >> >> 2007631496: a(n) ZnConnectionTimeout >> >> >> 0xbff5544c I ZnConnectionTimeout class(DynamicVariable >> >> >> class)>value:during: 2007997132: a(n) ZnConnectionTimeout class >> >> >> 0xbff55474 I ZnClient>withTimeoutDo: 2035558752: a(n) ZnClient >> >> >> 0xbff55498 I ZnClient>executeWithTimeout 2035558752: a(n) ZnClient >> >> >> 0xbff554bc I [] in ZnClient>execute 2035558752: a(n) ZnClient >> >> >> 0xbff554e0 I [] in ZnClient>withProgressDo: 2035558752: a(n) >> ZnClient >> >> >> 0xbff5550c I [] in ZnSignalProgress(DynamicVariable)>value:during: >> >> >> 2009919884: a(n) ZnSignalProgress >> >> >> 0xbff5552c M BlockClosure>ensure: 2035589476: a(n) BlockClosure >> >> >> 0xbff55558 I ZnSignalProgress(DynamicVariable)>value:during: >> >> >> 2009919884: a(n) ZnSignalProgress >> >> >> 0xbff55580 I ZnSignalProgress class(DynamicVariable >> >> >> class)>value:during: 2009919012: a(n) ZnSignalProgress class >> >> >> 0xbff555a8 I ZnClient>withProgressDo: 2035558752: a(n) ZnClient >> >> >> 0xbff555d4 I ZnClient>execute 2035558752: a(n) ZnClient >> >> >> 0xbff555f4 I ZnClient>get 2035558752: a(n) ZnClient >> >> >> 0xbff55614 I ZnClient>downloadTo: 2035558752: a(n) ZnClient >> >> >> 0xbff55640 I SmalltalkImage>downloadSources 2020677412: a(n) >> >> >> SmalltalkImage >> >> >> 0xbff55670 I SmalltalkImage>checkAndOpenSourcesAndChanges >> 2020677412: >> >> >> a(n) SmalltalkImage >> >> >> 0xbff55690 I SmalltalkImage>openSourceFiles 2020677412: a(n) >> >> >> SmalltalkImage >> >> >> 0xbff556a8 M SmalltalkImage class>startUp: 2020650272: a(n) >> >> >> SmalltalkImage >> >> >> class >> >> >> 0xbff556d0 M [] in SmalltalkImage>send:toClassesNamedIn:with: >> >> >> 2020677412: a(n) SmalltalkImage >> >> >> 0xbff556ec M BlockClosure>on:do: 2035540616: a(n) BlockClosure >> >> >> 0xbff5570c M SmalltalkImage>logStartUpErrorDuring:into:tryDebugger: >> >> >> 2020677412: a(n) SmalltalkImage >> >> >> >> >> >> >> >> >> so, it looks that we should not blame VM for 'black screen of >> death', >> >> >> but >> >> >> a startup code which stuck forever trying to download .sources file >> :) >> >> > >> >> > >> >> > You are right, when I add sources file next to NBCog, it works. Has >> >> > anyone >> >> > changed the scripts? >> >> > >> >> >> >> yes, guys added this nice feature lately.. but forgot to make it fault >> >> tolerant, i.e. >> >> >> >> downloadSources >> >> >> >> [ >> >> ......... >> >> >> >> ] on: ??Exception?? do: [ .. ok we failed.. continue without ] >> >> >> >> because without it, image will fail to work once you don't have >> >> network connection or simply cannot connect to urls.. for any other >> >> reason. >> > >> > >> > Yes, I know that function very well because it makes ugly dependency of >> the >> > kernel on Zinc ;-). But I was talking about scripts: >> > http://pharo.gforge.inria.fr/ci/ciPharo20NBCog.sh >> > http://pharo.gforge.inria.fr/ci/ciNBCog.sh >> > http://pharo.gforge.inria.fr/ci/ciPharo20.sh >> > >> >> but script works fine. image starts .. and then downloads .source file >> forever.. >> at least this is what happen on my ubuntu machine >> > > hmm, you are right, I looked at an older directory created this way some > time ago and the sources file has slightly newer time of creation. I > supposed that the file is dowloaded by bash. > > -- Pavel > I added an explicit download of the sources file to the Pharo Kernel Jobs. wget -O vm/PharoV10.sources http://pharo.gforge.inria.fr/ci/image/PharoV10.sources Maybe we should do that directly in the script. Pharo Kernel of course does not have Zinc support so it makes no sense to download it by an image by default. Cami, can you change that? We may add a special job to test downloadSources. -- Pavel > >> > -- Pavel >> > >> >> > -- Pavel >> >> > >> >> >> >> -- >> >> Best regards, >> >> Igor Stasenko. >> >> >> > >> >> >> >> -- >> Best regards, >> Igor Stasenko. >> >> >

Dec. 15, 2012

[Pharo-project] KeyChain/UsersManager

by Pavel Krivanek

Hi, what is the reason for integration of KeyChain/UsersManager to the image? It created the next kernel dependency. Should it replace Author? Should it be in the Pharo Kernel? And why there was no mention about it in this mailing list before? ;-) Cheers, -- Pavel

Dec. 15, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Janko MivÅ¡ek

Dne 15. 12. 2012 12:46, piÅ¡e Igor Stasenko: > Hold on.. Since when Pharo project became professional product? > How much money you and others paying for using it? > Yes, we position it as a product FOR professionals, > but does it automatically makes a professional one? > I don't think so. > So, why you think that it is correct to put such requirements/expectations it? Let me explain what I meant by 'professional product'. Product for professionals implies the characteristics of professional product. Even if it is an open source one and partially paid by donations. One of the main characteristic is a clear path of upgrading to a new version. Another is a proper 'Customer Relationship Management'. BTW, ask Gemstone guys for help here, they are very good in migration help to the new version and evolution to the new features. Not to mention their amazing attitude to the customers. To conclude, a bit better PR would make wonders here. Sometimes we need just to listen to our users even that we don't agree with them. Again one of the characteristics of professional product behavior, like it or not. Janko -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Dec. 15, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Janko MivÅ¡ek

Hi Esteban, I understand and support the cleanness focus, this is why Pharo actually seems very promising for the future. Just that cleaning should be gradual, in a sense that while introducing new you keep an old but clearly marked as obsolete for a, say, year or two. So that user base have a time to adapt to the new change. I think if you put the old FD in a ObsoleteFileDirectory package and load it by default for a year, then not anymore, this will certainly ease fears of some of us. Don't count me on this group, but I understand the guys, why don't like an approach you are going. Because it is user unfriendly even that a solution seems to be simple. Cleanness won't be hurt by that! Best regards Janko Dne 15. 12. 2012 12:49, piÅ¡e Esteban Lorenzano: > Let me explain this once again: we are not "backward compatibility > killer maniacs" :) > We prefer to keep backward compatibility whenever is possible, but we > don't put it as a top priority: if we find room to improve, we do it. > > but, since we take responsibility for all the packages loaded in what we > call "pharo", we rather prefer not to have duplicates, so we achieve one > of our goal (cleanness) while also focussing out effort. > > I'm sorry if that annoys some of you time to time, but that's the way to > improve: to change. > > Also... I think you are overreacting, in pharo 2.0 we just introduced > three big changes (visible to users): FS, SystemAnnouncer (who has, btw, > same API than old SystemChangeNotifier) and Nautilus... that's all. All > the other is infrastructure and shouldn't be a problem for anyone. > > Esteban > > On Dec 15, 2012, at 12:40 PM, Esteban Lorenzano <estebanlm(a)gmail.com > <mailto:estebanlm@gmail.com>> wrote: > >> Janko, >> that's already done (since ever), and FD is provided in two different >> ways: in the graveyard is the old FD package (loadable into pharo >> 2.0) http://smalltalkhub.com/#!/~Pharo/Graveyard20 , and also Camillo >> made a FD wrapper to FS... >> >> Esteban >> >> On Dec 15, 2012, at 12:31 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si >> <mailto:janko.mivsek@eranova.si>> wrote: >> >>> Dne 15. 12. 2012 12:12, piÅ¡e Igor Stasenko: >>>> On 15 December 2012 10:27, Janko MivÅ¡ek <janko.mivsek(a)eranova.si >>>> <mailto:janko.mivsek@eranova.si>> wrote: >>> >>>>> Is there any technical reason that the old FileDirectory stuff doesn't >>>>> stay and work in parallel to a new FileSystem? Maybe in some package >>>>> marked obsolete. Both use the same plugin and the same primitives, so >>>>> where is the problem? >>> >>>> Yes, there's one big reason: maintainability. And manpower. >>>> Who would like to maintain FD? Any takers? >>> >>> Gain with a (in this case very small) bit of manpower to ease upgrade to >>> new FS by providing existing FD for a while outweighs the loss by not >>> doing that. As a professional organization providing a professional >>> product Pharo should think rather that way. >>> >>> Janko >>> >>>> >>>>> >>>>> I also think that for a professionally viable product a clear migration >>>>> path should be provided. Progress yes, but user base must have a >>>>> guidance how to slowly migrate to the new functionality. If possible >>>>> with some automated procedure to migrate our code. >>>>> >>>>> In case of FileSystem/FileDirectory, this is certainly quite a big >>>>> change and will break a lot of code. Be sure therefore that you >>>>> guide us >>>>> as much as possible, otherwise there is a danger to loose a lot of user >>>>> base behind. >>>>> >>>> But there is a well-written documentation of FS. >>>> I wonder, if there's any documentation for FileDirectory ever existed. >>>> >>>>> Best regards >>>>> Janko >>>>> >>>>> Dne 15. 12. 2012 08:55, piÅ¡e StÃ©phane Ducasse: >>>>>> Chris >>>>>> >>>>>> Could you give us a break pleaseeeeeee? >>>>>> We are spending all our energy to build a better system that other >>>>>> people can use to make a living. >>>>>> May be we should just create a system for having fun in our teams? >>>>>> Because at the end of the day >>>>>> we just need to produce ideas and some prototypes (not even build >>>>>> them as researchers). >>>>>> >>>>>> I really think that there are still plenty of places where the >>>>>> system is not good. If you disagree then you may want to >>>>>> spend more time trying to extend it and build something real with >>>>>> it. (Here this is the place where you should react and prove >>>>>> to the world that you are a cool entrepreneur) ;D >>>>>> >>>>>> Now nobody force you to: >>>>>> - be in this mailing-list (you are welcome here but can we >>>>>> avoid this kind of endless useless discussions) or >>>>>> phrase your points with code snippet that can help the system. >>>>>> >>>>>> - use pharo in fact you are not using it so you are living in >>>>>> an happy world. So this is perfect. >>>>>> >>>>>> Did you read the Pharo motto? >>>>>> >>>>>> Stef >>>>>> >>>>>> >>>>>> On Dec 14, 2012, at 5:55 PM, Chris Muller wrote: >>>>>> >>>>>>> I'm tired of talking about this but I just can't let this go.. I >>>>>>> don't know if its just romantic, starry-eyed mountain climbers or >>>>>>> intentional false-propaganda but... confusion reigns here! :) This >>>>>>> example is bunk. >>>>>>> >>>>>>> Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002 >>>>>>> which, for whatever reason, is admittedly not great code but that's >>>>>>> not the point -- Sean is trying to use this example to >>>>>>> demonstrate how >>>>>>> using FileSystem will let you "scale new heights" over FileDirectory. >>>>>>> The real equivalent to what Sean wrote is: >>>>>>> >>>>>>> "FileDirectory" >>>>>>> localFileName: aString >>>>>>> | file | >>>>>>> super localFileName: aString. >>>>>>> file := FileDirectory directoryEntryFor: aString. >>>>>>> file exists ifFalse: [ ^ self ]. >>>>>>> self modifiedAt: file entry modificationTime. >>>>>>> >>>>>>> "FileSystem" >>>>>>> localFileName: aString >>>>>>> | file | >>>>>>> super localFileName: aString. >>>>>>> file := aString asFileName. >>>>>>> file exists ifFalse: [ ^ self ]. >>>>>>> self modifiedAt: file entry modificationTime. >>>>>>> >>>>>>> Ahhhh, I've broken all my systems but look how I'm scaling new >>>>>>> heights >>>>>>> with FileSystem! (not!) >>>>>>> >>>>>>> >>>>>>> >>>>>>> On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris >>>>>>> <sean(a)clipperadams.com <mailto:sean@clipperadams.com>> wrote: >>>>>>>> Chris Muller-4 wrote >>>>>>>>> While someone in the Pharo >>>>>>>>> community said FileSystem over FileDirectory is "huge", I see >>>>>>>>> it as an >>>>>>>>> incremental API change >>>>>>>> >>>>>>>> Can you still say that after reading >>>>>>>> http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?! >>>>>>>> >>>>>>>> FileSystem has hugely decremented the number of times I've >>>>>>>> wanted to throw >>>>>>>> my computer at a wall ;) FileDirectory occurred to me like >>>>>>>> graffiti painted >>>>>>>> on a great work of art. >>>>>>>> >>>>>>>> Multiply the above by every dark corner of the system and you >>>>>>>> have the >>>>>>>> barrier to the next stage of evolution. For myself, every time >>>>>>>> I've embarked >>>>>>>> on a bold new idea for our IDE, after getting bogged down in a >>>>>>>> mess of >>>>>>>> objects - like FileDirectory et al, or Paragraph and friends, or >>>>>>>> Morphic >>>>>>>> layout objects, and on and on - I reached a point where I was >>>>>>>> not willing to >>>>>>>> put in the tremendous effort required to understand the system >>>>>>>> (if even >>>>>>>> possible). And because few of the design decisions are >>>>>>>> documented, I didn't >>>>>>>> know how to clean things without breaking them. So, I gave up >>>>>>>> and just went >>>>>>>> back to the standard tools. >>>>>>>> >>>>>>>> I hate to keep repeating myself, but the Pharo manifesto is very >>>>>>>> clear, and >>>>>>>> makes these types of arguments moot: >>>>>>>> - Better for the better >>>>>>>> - Beauty to learn from >>>>>>>> - Not backward compatible >>>>>>>> - Clean, lean and fast >>>>>>>> >>>>>>>> Cheers, >>>>>>>> Sean >>>>> >>>>> -- >>>>> Janko MivÅ¡ek >>>>> Aida/Web >>>>> Smalltalk Web Application Server >>>>> http://www.aidaweb.si <http://www.aidaweb.si/> >>>>> >>>> >>>> >>>> >>> >>> -- >>> Janko MivÅ¡ek >>> Aida/Web >>> Smalltalk Web Application Server >>> http://www.aidaweb.si <http://www.aidaweb.si/> >>> >> > -- Janko MivÅ¡ek Aida/Web Smalltalk Web Application Server http://www.aidaweb.si

Dec. 15, 2012

Re: [Pharo-project] NB Types and C Types

by Igor Stasenko

On 14 December 2012 20:48, Jimmie Houchin <jlhouchin(a)gmail.com> wrote: > Hello, > > In my app using NB and have a few questions on types. > > In one function I have an size_t *arg > for an argument. Is NBUInt64 proper for this argument? > No. 'size_t*' is a pointer. A size_t type defined as an unsigned integer type, with range big enough to specify size(s) like array size, or a size of memory to allocate in bytes. On 32-bit systems size_t is unsigned 32-bit integer. And here how you can answer your question by yourself: NBFFICallout new resolveType: 'size_t*' > I also have a DATE which uses OLE Automation date format which is described > as: > > """ > An OLE Automation date is implemented as a floating-point number whose > integral component is the number of days before or after midnight, 30 > December 1899, and whose fractional component represents the time on that > day divided by 24. > """ > > Would NBUInt64 be best or is NBUInt32 a better fit? I haven't seen a method > for this particular date epoch, but I can easily write the method to handle > conversion. > No. The C double type has a special discipline for returning it from function: - it is returned in FP register, unlike rest which using EAX/EDX registers. So, if you use either NBUInt64 or NBUInt32 you won't be able to get actual values which function returns. So, you should use 'double' type, which is alias for NBFloat64 > Thanks for any wisdom and guidance. > > Jimmie -- Best regards, Igor Stasenko.

Dec. 15, 2012

Re: [Pharo-project] About (backwards) Compatibility

by Esteban Lorenzano

Let me explain this once again: we are not "backward compatibility killer maniacs" :) We prefer to keep backward compatibility whenever is possible, but we don't put it as a top priority: if we find room to improve, we do it. but, since we take responsibility for all the packages loaded in what we call "pharo", we rather prefer not to have duplicates, so we achieve one of our goal (cleanness) while also focussing out effort. I'm sorry if that annoys some of you time to time, but that's the way to improve: to change. Also... I think you are overreacting, in pharo 2.0 we just introduced three big changes (visible to users): FS, SystemAnnouncer (who has, btw, same API than old SystemChangeNotifier) and Nautilus... that's all. All the other is infrastructure and shouldn't be a problem for anyone. Esteban On Dec 15, 2012, at 12:40 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Janko, > that's already done (since ever), and FD is provided in two different ways: in the graveyard is the old FD package (loadable into pharo 2.0) http://smalltalkhub.com/#!/~Pharo/Graveyard20 , and also Camillo made a FD wrapper to FS... > > Esteban > > On Dec 15, 2012, at 12:31 PM, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: > >> Dne 15. 12. 2012 12:12, piÅ¡e Igor Stasenko: >>> On 15 December 2012 10:27, Janko MivÅ¡ek <janko.mivsek(a)eranova.si> wrote: >> >>>> Is there any technical reason that the old FileDirectory stuff doesn't >>>> stay and work in parallel to a new FileSystem? Maybe in some package >>>> marked obsolete. Both use the same plugin and the same primitives, so >>>> where is the problem? >> >>> Yes, there's one big reason: maintainability. And manpower. >>> Who would like to maintain FD? Any takers? >> >> Gain with a (in this case very small) bit of manpower to ease upgrade to >> new FS by providing existing FD for a while outweighs the loss by not >> doing that. As a professional organization providing a professional >> product Pharo should think rather that way. >> >> Janko >> >>> >>>> >>>> I also think that for a professionally viable product a clear migration >>>> path should be provided. Progress yes, but user base must have a >>>> guidance how to slowly migrate to the new functionality. If possible >>>> with some automated procedure to migrate our code. >>>> >>>> In case of FileSystem/FileDirectory, this is certainly quite a big >>>> change and will break a lot of code. Be sure therefore that you guide us >>>> as much as possible, otherwise there is a danger to loose a lot of user >>>> base behind. >>>> >>> But there is a well-written documentation of FS. >>> I wonder, if there's any documentation for FileDirectory ever existed. >>> >>>> Best regards >>>> Janko >>>> >>>> Dne 15. 12. 2012 08:55, piÅ¡e StÃ©phane Ducasse: >>>>> Chris >>>>> >>>>> Could you give us a break pleaseeeeeee? >>>>> We are spending all our energy to build a better system that other people can use to make a living. >>>>> May be we should just create a system for having fun in our teams? Because at the end of the day >>>>> we just need to produce ideas and some prototypes (not even build them as researchers). >>>>> >>>>> I really think that there are still plenty of places where the system is not good. If you disagree then you may want to >>>>> spend more time trying to extend it and build something real with it. (Here this is the place where you should react and prove >>>>> to the world that you are a cool entrepreneur) ;D >>>>> >>>>> Now nobody force you to: >>>>> - be in this mailing-list (you are welcome here but can we avoid this kind of endless useless discussions) or >>>>> phrase your points with code snippet that can help the system. >>>>> >>>>> - use pharo in fact you are not using it so you are living in an happy world. So this is perfect. >>>>> >>>>> Did you read the Pharo motto? >>>>> >>>>> Stef >>>>> >>>>> >>>>> On Dec 14, 2012, at 5:55 PM, Chris Muller wrote: >>>>> >>>>>> I'm tired of talking about this but I just can't let this go.. I >>>>>> don't know if its just romantic, starry-eyed mountain climbers or >>>>>> intentional false-propaganda but... confusion reigns here! :) This >>>>>> example is bunk. >>>>>> >>>>>> Sean chose a method in ZipDirectoryMember written by Ned Konz in 2002 >>>>>> which, for whatever reason, is admittedly not great code but that's >>>>>> not the point -- Sean is trying to use this example to demonstrate how >>>>>> using FileSystem will let you "scale new heights" over FileDirectory. >>>>>> The real equivalent to what Sean wrote is: >>>>>> >>>>>> "FileDirectory" >>>>>> localFileName: aString >>>>>> | file | >>>>>> super localFileName: aString. >>>>>> file := FileDirectory directoryEntryFor: aString. >>>>>> file exists ifFalse: [ ^ self ]. >>>>>> self modifiedAt: file entry modificationTime. >>>>>> >>>>>> "FileSystem" >>>>>> localFileName: aString >>>>>> | file | >>>>>> super localFileName: aString. >>>>>> file := aString asFileName. >>>>>> file exists ifFalse: [ ^ self ]. >>>>>> self modifiedAt: file entry modificationTime. >>>>>> >>>>>> Ahhhh, I've broken all my systems but look how I'm scaling new heights >>>>>> with FileSystem! (not!) >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Dec 12, 2012 at 10:39 PM, Sean P. DeNigris >>>>>> <sean(a)clipperadams.com> wrote: >>>>>>> Chris Muller-4 wrote >>>>>>>> While someone in the Pharo >>>>>>>> community said FileSystem over FileDirectory is "huge", I see it as an >>>>>>>> incremental API change >>>>>>> >>>>>>> Can you still say that after reading >>>>>>> http://forum.world.st/The-Magic-of-FileSystem-td4635471.html ?! >>>>>>> >>>>>>> FileSystem has hugely decremented the number of times I've wanted to throw >>>>>>> my computer at a wall ;) FileDirectory occurred to me like graffiti painted >>>>>>> on a great work of art. >>>>>>> >>>>>>> Multiply the above by every dark corner of the system and you have the >>>>>>> barrier to the next stage of evolution. For myself, every time I've embarked >>>>>>> on a bold new idea for our IDE, after getting bogged down in a mess of >>>>>>> objects - like FileDirectory et al, or Paragraph and friends, or Morphic >>>>>>> layout objects, and on and on - I reached a point where I was not willing to >>>>>>> put in the tremendous effort required to understand the system (if even >>>>>>> possible). And because few of the design decisions are documented, I didn't >>>>>>> know how to clean things without breaking them. So, I gave up and just went >>>>>>> back to the standard tools. >>>>>>> >>>>>>> I hate to keep repeating myself, but the Pharo manifesto is very clear, and >>>>>>> makes these types of arguments moot: >>>>>>> - Better for the better >>>>>>> - Beauty to learn from >>>>>>> - Not backward compatible >>>>>>> - Clean, lean and fast >>>>>>> >>>>>>> Cheers, >>>>>>> Sean >>>> >>>> -- >>>> Janko MivÅ¡ek >>>> Aida/Web >>>> Smalltalk Web Application Server >>>> http://www.aidaweb.si >>>> >>> >>> >>> >> >> -- >> Janko MivÅ¡ek >> Aida/Web >> Smalltalk Web Application Server >> http://www.aidaweb.si >> >

Dec. 15, 2012