- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Recent changes in Bloc, no more BlMorph

by stepharo

Le 5/2/16 13:51, Sean P. DeNigris a Ã©crit : > Aliaksei Syrel wrote >> Root element is BlElement. No more BlView. Added BlShape and BlPath. > Would you summarize that design decision? oh boy: 50 emails, chat over skype, visit of aleksei to Brest during 3 days, breaking Bloc core.... So alex can try :) Stef > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Recent-changes-in-Bloc-no-more-BlMorph-tp4875999p4876… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

Feb. 6, 2016

[bloc] a little demo

by stepharo

Hi guys aleksei, glenn, alain shaked deeply bloc and slowly bloc is getting backing shape. We are moving now the discussions to the pharo-dev mailing-list https://drive.google.com/file/d/0B-bMBVDOi3oTTDBxNmdfS0o3S3c/view?pref=2&pl…

Feb. 6, 2016

Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)

by Ben Coman

On Sat, Feb 6, 2016 at 12:59 PM, Martin Dias <tinchodias(a)gmail.com> wrote: > In fact, this integration step > (https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z) was > already passed by Epicea in December. That was before spur, it might be > related to spur. > > That time, the integration of Epicea revealed a bug in delay's scheduling... Was that these issues integrated in build 50466... https://pharo.fogbugz.com/default.asp?17066 https://pharo.fogbugz.com/default.asp?13756 which should have left the current scheduler as DelayExperimentalSpinScheduler but in current build 50564 "Delay delaySchedulerClass" --> DelayMicrosecondScheduler Maybe Delay class >> initialize has been executed since Scheduler ifNotNil: [ Scheduler stopTimerEventLoop ]. Scheduler := DelayMicrosecondScheduler new. Scheduler startTimerEventLoop. Smalltalk addToStartUpList: self. but I don't see any updates that might have invoked it. Anyway, maybe changing that will help. cheers -ben > maybe now it's revealing some bug in Windows+spur...? > > Martin > > > On Fri, Feb 5, 2016 at 10:09 AM, Blondeau Vincent > <vincent.blondeau(a)worldline.com> wrote: >> >> If you remove any line, it stops crashingâ¦ >> >> I really donât know what is going onâ¦ >> >> >> >> Vincent >> >> >> >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de >> Henrik Nergaard >> EnvoyÃ© : vendredi 5 fÃ©vrier 2016 14:03 >> >> >> Ã : Pharo Development List >> Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] >> We are in "code freeze" for Pharo 5) >> >> >> >> Removing >> >> #(IRPrinterV2 #(visitStoreTemp: visitStoreRemoteTemp: >> visitPopIntoLiteralVariable: visitPushTemp: visitReturnLiteral: >> visitStoreInstVar: visitStoreLiteralVariable: visitPushLiteralVariable: >> visitPushInstVar: visitJump: visitPushLiteral: label: visitPushArray: >> visitPopIntoTemp: visitReturnInstVar: visitPopIntoRemoteTemp: >> visitTempVector: visitJumpIf: visitPushRemoteTemp: visitPopIntoInstVar: >> visitSend: )) >> >> And it stops crashing. >> >> >> >> - BTW, there is not crash.dmp, does it works with spur? >> >> >> https://pharo.fogbugz.com/f/cases/17506/when-an-Image-crashes-a-crash-dmp-f… >> >> >> >> Best regards, >> >> Henrik >> >> >> >> From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of >> Blondeau Vincent >> Sent: Friday, February 5, 2016 1:54 PM >> To: Pharo Development List <pharo-dev(a)lists.pharo.org> >> Subject: Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: >> [ANN] We are in "code freeze" for Pharo 5) >> >> >> >> Very strange bug indeed that happens on windows machines that crashes the >> VM. I succeeded to reduce the problem to an evaluation of a collectionâ¦ >> >> Can someone have the same issue under Windows or Mac? >> >> >> >> To reproduce : Copy paste the contents of the attached file in the >> playground and print it or do it >> >> It works on pre-spur vm. >> >> >> >> BTW, there is not crash.dmp, does it works with spur? >> >> Vincent >> >> >> >> De : Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] De la part de >> Marcus Denker >> EnvoyÃ© : vendredi 5 fÃ©vrier 2016 13:01 >> Ã : Pharo Development List >> Objet : Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] >> We are in "code freeze" for Pharo 5) >> >> >> >> >> >> On 05 Feb 2016, at 12:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: >> >> >> >> I will try do integrate it nowâ¦ >> >> >> >> >> >> >> >> No, it still fails. >> >> >> >> >> https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/labe… >> >> >> >> The last test it executed seems to be this: >> >> running suite: Refactoring-Tests-Environment >> >> starting testcase: RBBrowserEnvironmentTest>>testAndEnvironment ... >> >> Very strange... >> >> Marcus >> >> >> >> >> >> ________________________________ >> >> >> Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage >> exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret >> professionnel. Si vous recevez ce message par erreur, merci d'en avertir >> immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne >> pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra >> Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs >> efforts soient faits pour maintenir cette transmission exempte de tout >> virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa >> responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un >> virus transmis. >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive this >> e-mail in error, please notify the sender immediately and destroy it. As its >> integrity cannot be secured on the Internet, the Worldline liability cannot >> be triggered for the message content. Although the sender endeavours to >> maintain a computer virus-free network, the sender does not warrant that >> this transmission is virus-free and will not be liable for any damages >> resulting from any virus transmitted. >> >> >> ________________________________ >> >> Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage >> exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret >> professionnel. Si vous recevez ce message par erreur, merci d'en avertir >> immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne >> pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra >> Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs >> efforts soient faits pour maintenir cette transmission exempte de tout >> virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa >> responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un >> virus transmis. >> >> This e-mail and the documents attached are confidential and intended >> solely for the addressee; it may also be privileged. If you receive this >> e-mail in error, please notify the sender immediately and destroy it. As its >> integrity cannot be secured on the Internet, the Worldline liability cannot >> be triggered for the message content. Although the sender endeavours to >> maintain a computer virus-free network, the sender does not warrant that >> this transmission is virus-free and will not be liable for any damages >> resulting from any virus transmitted. > >

Feb. 6, 2016

Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: [ANN] We are in "code freeze" for Pharo 5)

by Martin Dias

In fact, this integration step ( https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z <https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/labe…>) was already passed by Epicea in December. That was before spur, it might be related to spur. That time, the integration of Epicea revealed a bug in delay's scheduling... maybe now it's revealing some bug in Windows+spur...? Martin On Fri, Feb 5, 2016 at 10:09 AM, Blondeau Vincent < vincent.blondeau(a)worldline.com> wrote: > If you remove any line, it stops crashingâ¦ > > I really donât know what is going onâ¦ > > > > Vincent > > > > *De :* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] *De la part > de* Henrik Nergaard > *EnvoyÃ© :* vendredi 5 fÃ©vrier 2016 14:03 > > *Ã :* Pharo Development List > *Objet :* Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: > [ANN] We are in "code freeze" for Pharo 5) > > > > Removing > > #(IRPrinterV2 #(visitStoreTemp: visitStoreRemoteTemp: > visitPopIntoLiteralVariable: visitPushTemp: visitReturnLiteral: > visitStoreInstVar: visitStoreLiteralVariable: visitPushLiteralVariable: > visitPushInstVar: visitJump: visitPushLiteral: label: visitPushArray: > visitPopIntoTemp: visitReturnInstVar: visitPopIntoRemoteTemp: > visitTempVector: visitJumpIf: visitPushRemoteTemp: visitPopIntoInstVar: > visitSend: )) > > And it stops crashing. > > > > - BTW, there is not crash.dmp, does it works with spur? > > > https://pharo.fogbugz.com/f/cases/17506/when-an-Image-crashes-a-crash-dmp-f… > > > > Best regards, > > Henrik > > > > *From:* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org > <pharo-dev-bounces(a)lists.pharo.org>] *On Behalf Of *Blondeau Vincent > *Sent:* Friday, February 5, 2016 1:54 PM > *To:* Pharo Development List <pharo-dev(a)lists.pharo.org> > *Subject:* Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: > [ANN] We are in "code freeze" for Pharo 5) > > > > Very strange bug indeed that happens on windows machines that crashes the > VM. I succeeded to reduce the problem to an evaluation of a collectionâ¦ > > Can someone have the same issue under Windows or Mac? > > > > To reproduce : Copy paste the contents of the attached file in the > playground and print it or do it > > It works on pre-spur vm. > > > > BTW, there is not crash.dmp, does it works with spur? > > Vincent > > > > *De :* Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org > <pharo-dev-bounces(a)lists.pharo.org>] *De la part de* Marcus Denker > *EnvoyÃ© :* vendredi 5 fÃ©vrier 2016 13:01 > *Ã :* Pharo Development List > *Objet :* Re: [Pharo-dev] Epicea tests failure under Windows (WAS: RE: > [ANN] We are in "code freeze" for Pharo 5) > > > > > > On 05 Feb 2016, at 12:40, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > > I will try do integrate it nowâ¦ > > > > > > > > No, it still fails. > > > > > https://ci.inria.fr/pharo/job/Pharo-5.0-Update-Step-2.1-Validation-M-Z/labe… > > > > The last test it executed seems to be this: > > running suite: Refactoring-Tests-Environment > > starting testcase: RBBrowserEnvironmentTest>>testAndEnvironment ... > > Very strange... > > Marcus > > > > > ------------------------------ > > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. > > ------------------------------ > > Ce message et les piÃ¨ces jointes sont confidentiels et rÃ©servÃ©s Ã l'usage > exclusif de ses destinataires. Il peut Ã©galement Ãªtre protÃ©gÃ© par le secret > professionnel. Si vous recevez ce message par erreur, merci d'en avertir > immÃ©diatement l'expÃ©diteur et de le dÃ©truire. L'intÃ©gritÃ© du message ne > pouvant Ãªtre assurÃ©e sur Internet, la responsabilitÃ© de Worldline ne pourra > Ãªtre recherchÃ©e quant au contenu de ce message. Bien que les meilleurs > efforts soient faits pour maintenir cette transmission exempte de tout > virus, l'expÃ©diteur ne donne aucune garantie Ã cet Ã©gard et sa > responsabilitÃ© ne saurait Ãªtre recherchÃ©e pour tout dommage rÃ©sultant d'un > virus transmis. > > This e-mail and the documents attached are confidential and intended > solely for the addressee; it may also be privileged. If you receive this > e-mail in error, please notify the sender immediately and destroy it. As > its integrity cannot be secured on the Internet, the Worldline liability > cannot be triggered for the message content. Although the sender endeavours > to maintain a computer virus-free network, the sender does not warrant that > this transmission is virus-free and will not be liable for any damages > resulting from any virus transmitted. >

Feb. 6, 2016

Re: [Pharo-dev] [Vm-dev] Where to get Monitor implementation based on primitives?

by Ben Coman

On Fri, Jan 8, 2016 at 9:39 PM, Ben Coman <btc(a)openinworld.com> wrote: > > btw, Looking at the following... > CriticalSection>>critical: aBlock > ^self primitiveEnterCriticalSection > ifTrue: [aBlock value] > ifFalse: [aBlock ensure: [self primitiveExitCriticalSection]] > > without intimate VM knowledge but seeing Eliot recently say > "invocations of methods with primitives [...] are not suspension > points, unless their primitives fail" -- I'm paranoid that since > #ensure: primitive 198 always fail, there might be some some small > window for a race where a process might be terminated before > #primitiveExitCriticalSection can be executed. I'll take a refutation > of this to improve the method comment. > > The following instils more confidence... > > CriticalSection2>>critical: aBlock > | reEntered | > reEntered := false. > [ reEntered := self primitiveEnterCriticalSection. > aBlock value ] ensure: > [ reEntered ifFalse: [ self primitiveExitCriticalSection] ] Having spent more time considering this, I found I was off track here. If a process waiting at #primitiveEnterCriticalSection is terminated, then #primitiveExitCriticalSection is erroneously executed. And it will be the same problem with the proposal for Case17373 based on OwnedLock>>acquire Mutex>>critical: aBlock | lockAcquiredNotHere | <lockAt: #lock tracksStateAt: 1> lockAcquiredNotHere := true. ^[ lockAcquiredNotHere := false. lockAcquiredNotHere := lock acquire. aBlock value ] ensure: [lockAcquiredNotHere ifFalse: [lock release]]. So now I believe the original #critical: proposed by Eliot is optimal. * If #primitiveEnterCriticalSection is terminated while waiting, then the #ifFalse: is never executed. * When #primitiveEnterCriticalSection returns, the inlined #ifTrue:ifFalse cant be interrupted. * #ensure is a primitive which can't be interrupted. By the time it has done its usual "fail", which I raised concern over, actually it has already done its job to make sure #primitiveExitCriticalSection is executed.

Feb. 6, 2016

Re: [Pharo-dev] [Vm-dev] Simple versus Recursive Mutexes

by Ben Coman

On Fri, Feb 5, 2016 at 1:16 AM, Ben Coman <btc(a)openinworld.com> wrote: > On Wed, Feb 3, 2016 at 2:35 AM, Eliot Miranda <eliot.miranda(a)gmail.com> wrote: >> Hi Ben, >> >> On Tue, Feb 2, 2016 at 9:54 AM, Ben Coman <btc(a)openinworld.com> wrote: >>> >>> >>> While we are in the process of revising the Mutex infrastructure [1] >>> to use dedicated primitives rather than rely on counting via a >>> semaphore, I want to raise the question of simple versus recursive >>> mutexes. >>> >>> This isn't something I know much about, except that some people >>> strongly believe recursive mutexes are evil, including David Butenhof >>> who apparently was the guy who added recursive mutexes to POSIX "on a >>> dare [...] but nobody was supposed to use recursive mutexes." [1]. >>> >>> There are two interesting discussion on stockoverflow [2][3]. But btw >>> I disagree with Tall Jeff [3] says "The difference between a recursive >>> and non-recursive mutex has to do with ownership. " I think he >>> confuses a simple-mutex and binary-semaphore, as do a some commenters. >>> >>> "Prefer Simple Mutex Over Recursive Mutex" [4] demonstrates some >>> performance considerations and advises "a recursive mutex is dangerous >>> because you lose sense of locking scope. It costs more than a simple >>> mutex." >>> >>> "Recursive Locks Will Kill You!" [5] provides some thread safety >>> guidelines. >>> >>> Finally, there is a paper "Ad Hoc Synchronization Considered harmful" >>> [6], which I haven't read yet since I wanted to get this post out >>> before heading to bed, but I hope to tomorrow. >>> >>> >>> [1] http://www.zaval.org/resources/library/butenhof1.html >>> [2] http://stackoverflow.com/questions/2415082/when-to-use-recursive-mutex >>> [3] >>> http://stackoverflow.com/questions/187761/recursive-lock-mutex-vs-non-recur… >>> [4] >>> http://askldjd.com/2009/10/26/prefer-simple-mutex-over-recursive-mutex/ >>> [5] >>> http://www.fieryrobot.com/blog/2008/10/14/recursive-locks-will-kill-you/ >>> [6] https://www.usenix.org/legacy/event/osdi10/tech/full_papers/Xiong.pdf >>> >>> >>> So our existing Mutex implementation happens to be recursive, and I'm >>> not suggesting we change that. However if we should consider *not* >>> baking the *assumption* of recursion into the primitives, so the same >>> primitives could *also* be used for a SimpleMutex class. The logic to >>> provide recursion for Mutex is only [ owner = activeProcess ] which is >>> easily done in-image. >>> >>> So I propose introducing aquire/release primitives based off the >>> existing critical section primitives with the recursion removed. >> >> >> We have two sets of primitives, the queueing semaphore ones, signal and >> wait, #85 & #86, which are not recursive, and new ones, #185, #186 & #187 >> that support ownership, and hence support recursion. It makes no sense to >> remove the recursion support. That's what the primitives are for, to >> provide ownership support as efficiently as possible. Please don't be led >> by the problems others may have in other systems, and instead be led by how >> we're doing. Squeak and Pharo (and Smalltalk) have had recursive owned >> critical sections for decades and no one (e.g. from demanding industrial >> control applications) has complained that these recursive critical sections >> are problematic. > > I respect your deep experience, but there is an engineering principle > that "just because it works, doesn't mean its correct. It may just > be reinforcing some misconceptions" ;) > > Several reasons why people may not complain... > 1. the expectation its been there so long that its correct > 2. the expectation expert people worked on it so its correct > 3. subtle bugs remain latent or trigger infrequently, thus hard to isolate > 4. when bugs arise, they are fixed pragmatically without deeper > philosophical consideration > 5. coincidently other good programming practices avoided problematic situations > 6. Threads run concurrently and co-operatively, so maybe in practice > there are less issues than a parallel and pre-emptive systems. Okay class... your new word for the day is "hubris". It was hubris for me to lay it out like that. It was easy to think I could do better from a distant hand waving perspective, but having spent a few hours in the trenches playing concretely with the primitive code, I've realised the current primitiveEnterCriticalSection is optimum. > I would think a thread doing an in-image (owner = activeProcess) test > would be unaffected by suspension points since it doesn't change any > state and only the same thread would have set owner via the primitive. >> The new primitives give us a streamlined and hack-free >> implementation which doesn't depend on the niceties of what are suspension >> points as do the pre-primitive implementations. So I see no rationale for >> gelding these primitives. You are right. Actually, as Dennis indicated, the existing primitive already provides everything needed... RecursiveMutex>>critical: aBlock ^self primitiveEnterCriticalSection ifTrue: [aBlock value] ifFalse: [aBlock ensure: [self primitiveExitCriticalSection]] SimpleMutex>>critical: aBlock ^self primitiveEnterCriticalSection ifTrue: [self error: 'recursive primitives will kill you'] ifFalse: [aBlock ensure: [self primitiveExitCriticalSection]] duh, me! Well, it was a useful learning process for me to play with the primitive. I'm may have some further thoughts on the exit primitive, but they are still forming, so I'll leave for a separate post. cheers -ben

Feb. 6, 2016

Re: [Pharo-dev] Ubuntu with Spur

by Damien Cassou

On February 5, 2016 8:07:38 PM GMT+01:00, Torsten Bergmann <astares(a)gmx.de> wrote: >Is Spur already in the PPA for last stable Ubuntu or how >do I install latest spur quickly using commandline? > >Should I use zeroconf from get.pharo.org. Does it >run on latest dev version of Ubuntu? > >Thanks >T. I updated the source repository. Now, Markus must upload a new deb release. In the meantime, you can use get.pharo.org or http://nixos.org/nixpkgs/ -- Damien Cassou http://damiencassou.seasidehosting.st "Success is the ability to go from one failure to another without losing enthusiasm." --Winston Churchill

Feb. 5, 2016

Ubuntu with Spur

by Torsten Bergmann

Is Spur already in the PPA for last stable Ubuntu or how do I install latest spur quickly using commandline? Should I use zeroconf from get.pharo.org. Does it run on latest dev version of Ubuntu? Thanks T.

Feb. 5, 2016

Easy way to change "move between words" to alt key in OSX?

by Mariano Martinez Peck

Hi guys, It happens to me that I got so used to work in Pharo and "move between words" with ctrl key, that then, whenever I use any other program of OSX, I get crazy because in many programs ctrl+arrow is for going start/end of file. Same for command. It seems to me that using alt + arrow for moving between words is the most common in OSX. So....is there a way to set this via preferences or something? Thanks in advance, -- Mariano http://marianopeck.wordpress.com

Feb. 5, 2016

Re: [Pharo-dev] Contributing to Pharo

by Thierry Goubier

Le 05/02/2016 14:55, Christophe Demarey a Ã©crit : > > Le 5 fÃ©vr. 2016 Ã 14:33, Thierry Goubier a Ã©crit : > >> Le 05/02/2016 11:33, Christophe Demarey a Ã©crit : >>> Hi Thierry, >>> >>> Just some thoughts I wanted to share: >>> >>> Le 3 fÃ©vr. 2016 Ã 10:18, Thierry Goubier a Ã©crit : >>> >>>> I went through all the different possible file formats, >>>> class-based, package-based, method-based, log metadata and the >>>> like, and I concluded that: >>>> >>>> - the method based format is as good as any other. Even better >>>> since it has a spec (cypress). >>> >>> I see cons that a class (or package) format would not have. One >>> file per method approach leads to generate plenty of small files. >>> In general, file systems do not like that: - it may consumes a >>> lot of space. I remember I had a Java/maven project with a lot of >>> small files and I got to fill the inodes tables on my unix >>> system. - you generate long pathes. Long pathes are not >>> user-friendly and some OS have restrictions on path length. >> >> The method based structure of filetree is very close to how code is >> navigated in Smalltalk browsers: one method at a time, with a >> package/class/protocol hierarchical layering on top. The one file >> per class / one file per package is a reference to the base unit of >> C / C++. > > I fully agree with that. As we have a lot (small) methods, we will > have a lot of small files and some file-system does not like that. I > remember huge slow-down be cause of that. It is good to keep that in > mind. The problem is linked with writing too many files. Because of a possible uncertainty about the on-disk state, FileTree erase the complete package directory then rewrites everything, letting the vcs decide what has really changed. This is doubly slow, because it hits the filesystem and the vcs. I said to Dale I'd see into a diff based writer; it should improve things a lot. >> And no OS in general use has path restrictions that matter. Ok, the >> windows vm has issues, but this is a vm bug, not a filesystem >> issue. > > Windows command-line has (had) this limitation. Good to know. >>> By adopting a file per method approach, you also increase the >>> distance to get a common script format for Smalltalk. Here I mean >>> a file where you could define classes, methods, and run >>> arbitrary portions of Smalltalk code. >> >> This format is called fileout, and already exist. > > I mean something like a python script: > http://archive.stsci.edu/vo/python_examples.html Not entirely keen in going that way. I prefer declarative formats for storing packages. And I still think that the fileout format is that (a sequence of scripts to execute, separated by !!). >> All you describe is also available in the FileTree/Cypress format >> and is technically better specified. >> >>>> - method based format allow for method-history queries on the >>>> git/vcs history (as well as class based / package based >>>> queries). - the tree structure on github or bitbucket is quite >>>> convenient (and browsable) to the point one could edit a >>>> package directly in it (I do when I need to do a quick fix). >>> >>> but is a pain to navigate: too much click to effectively browse >>> a method content. >> >> You must hate Nautilus, then, since this is Nautilus approach as >> well. Just count the number of clicks you do in a Nautilus, and the >> number in github. > > but we have spotter! (I just miss the exact search to not click and > scroll too much) Then you want spotter on the web :) >> If we remove the instance sub-directory and write instance-side >> methods just below the class name in filetree, then you'll get the >> exact same number of clicks to reach a method than in Nautilus. > > it would be a good idea Why not. >> Fun fact: if you do that with the Mac finder in NexT mode over a >> filetree repository (miller columns), you'll see that it almost >> looks like a Nautilus top panes. >> >>> I do not know what would be the best format but I think we need >>> to take care to do not generate too much files / folders. File >>> system and VCS will appreciate also. >> >> I'd say, overall, what we need to remember is that we produce a >> lot less lines of code than other languages, and that we shouldn't >> over-optimize. >> >> I'll probably look into optimising FileTree-like writing in the >> future; I wasn't that good into planning for it and it shows in >> specific cases. > > It is actually the problem: we generate a lot of small files. I do > not have numbers but I think it would be good to stress a bit a file > system to see where we hit the barrier and compare with the pharo > code base. From the git side, I'm not aware of a limitation regarding > small files. I'm sure the numbers are already available. And, as I said above, you may be measuring FileTree implementation limitations and nothing related to filesystem issues (or git issues). Thierry

Feb. 5, 2016