May 2015 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] could the log message be placed on top of the files in the commit?

by Nicolas Cellier

2015-05-03 21:56 GMT+02:00 Nicolas Cellier < nicolas.cellier.aka.nice(a)gmail.com>: > > > 2015-05-03 18:54 GMT+02:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > >> do you guys know that if you press in the link provided, for example: >> >> >> https://github.com/pharo-project/pharo-core/commit/cf09b156e5bc943d6b99a340… >> >> you will have all the diffs well organised and for free? >> >> Esteban >> >> ps: in fact, if possible, I wouldnât publish even the list of files >> changedâ¦ just the commit message and the link >> >> > Yes, message and link would be just enough. > And while asking, maybe more atomic commits (single issue at a time). > > Beside, non atomic commits will introduce an expressiveness bias, at least as approximated by http://redmonk.com/dberkholz/2013/03/25/programming-languages-ranked-by-exp… ;) > >> On 03 May 2015, at 18:23, stepharo <stepharo(a)free.fr> wrote: >> >> >> Code diffs would be more valuable, but adopting the tools of file lovers >> must come with a cost ;) >> >> >> Yes I would love that too. >> I just want to compile a list of changes automatically. >> May I can do in the scriptLoader instead of reparsing git. >> >> >> >

May 11, 2015

Re: [Pharo-dev] Transcript needs your love

by Alain Rastoul

Le 11/05/2015 23:32, Igor Stasenko a Ã©crit : > Don't think i am overreacting on Eliot's overreacting whatever.. > We're a good friends, and pike fight on mailing list is not gonna change > that. > I just stating my POV, he stating own.. and that's how i see it, if you > remove the giggles:). Good to know that, because there was no such evidence reading the thread... >> So, why complaining? Why not just do it. Or do you think i will scream > 'over my dead body' or what? If you know how to make it better, do it. I tried to import CuisTranscript in pharo today but had some morphic issues. It is not complex at all, but I am bad at morphic and don't like it. I am not at all doing that because I know how to do it better, just to help to not be forced to use squeak to go into vm internals, as I would like to some times. I really don't like using squeak, just a matter of taste, no criticism > I popped-out here mainly to explain the motivation of changes we did,and to > point out on the problems we had in the past and shared some insights how i > would deal with it. > nice, and also I liked your tales :) > > One thing at a time. I don't think it is too hard to do, or make things > overly complex. What is true,is that we got little or no > incentive/resources among people, to do that. > > yes, resources is often the problem -- Regards, Alain

May 11, 2015

Re: [Pharo-dev] Lighthouse example throw segfault

by Nicolai Hess

I don't know what lighthouse is about, but at least on windows, it does not segfault. But we have at least two issues of fogbugz about fullscreen on a mac: 12648 <https://pharo.fogbugz.com/default.asp?12648> Full screen on Mac OS X 10.9 partially broken 13995 <https://pharo.fogbugz.com/default.asp?13995> Recent Windows VM does not reopen fullscreen images in fullscreen (broken between 246 and 248 VM) This is about windows and was fixed, but in another issue, marked as duplicate of this issue: 15217 <https://pharo.fogbugz.com/default.asp?15217> Ben commented, that this is still an issue for mac, because the image crashes (see last comment https://pharo.fogbugz.com/default.asp?15217#BugEvent.123867) cheers nicolai 2015-05-11 22:32 GMT+02:00 Alejandro Infante <alejandroinfante91(a)gmail.com>: > > > On May 11, 2015, at 4:43 PM, stepharo <stepharo(a)free.fr> wrote: > > > > Hi alejandro > > > > which image? > â For the already built image, I used the version of May 9th (Build #467) > and is based on Pharo 3 > â For the one that I loaded the stable code using the last ConfigurationOf > (commit number 13) on a Pharo4.0 image (#40611) > > which version? > Guess this is answered up there. > > which latest vm? > Iâm not sure how to get this, sending --version or --help do not work. > Even though, comparing the creation date of the file of the VM, I guess > that is PharoVM 421.zip from the fileserver. > > > > do you see a pattern :) > 5 minutes ago I tried to using a different vm. Using the PharoS VM > (206.zip from the pharo fileserver) I wasnât able to reproduce the error. > > > > Stef > > > > Le 11/5/15 20:37, Alejandro Infante a Ã©crit : > >> Hello, > >> > >> When I try to open the image from Jenkins the screen goes black for 5 > seconds and then it throws a segmentation fault in my Mac. I use a Macbook > air with the latest stable Pharo VM. > >> > >> Using the ConfigurationOf I have found that Lighthouse by default set > the display to work in fullscreen, and is perfectly usable, but when saving > the image it is impossible to open it again (segfault). I attached the > crash.dmp. > >> > >> If I try to disable the fullscreen before saving it, the error does not > appear again. > >> > >> Iâm the only one capable to reproduce this? > >> > >> Cheers, > >> Alejandro > >> > > > > > > Cheers, > Alejandro > > >

May 11, 2015

Re: [Pharo-dev] Transcript needs your love

by Igor Stasenko

On 11 May 2015 at 22:54, Igor Stasenko <siguctua(a)gmail.com> wrote: > Speaking about penetrating multiple layers.. Lemme tell you the story: > > One day, a brave hero (let's call him Stef :) ) decided to save the > world... err improve Transcript and make it thread-safe. > And everything vent well until he stumbled upon #endEntry logic, because > he was unable to figure out how it is handled and where it is handled.. > He asked me for help and we sat together and looked for what can be done.. > After many months and fierce battles (longer that any developer would > except), we finally discovered that #endEntry logic is handled .. > (drumroll...) in TextMorph, > as a separate case in case-statement in its #changed: method. > > Sure it was a long ago, and my memory could fail me, i might be completely > wrong on some details, and maybe instead we were drinking ale with fairies > in the pub, and there was no any fights. But that's what is fairy tale for > :) > > I keep coming to this, so you guys can understand what is it.. There's a fairy tale in our culture where hero needs to kill an Immortal King, and he asked for advice from old which that told him how to do it: - there's a Mammoth, inside it a wolf, and inside wolf a rabbit, and inside rabbit - a duck, and inside duck, an egg, and inside egg a needle, and once you break the needle, so the Immortal King will be dead.. So, to recap, in order to kill an Immortal King, one must kill mammoth, wolf, rabbit, duck, break an egg and here we are.. job done! Now what is good and cool for fairy tale, not that cool and and suitable for daily programming tasks.. If one needs to break a needle - there should be a way to do just that, without need to peruse through piles of dead animal victims to achieve the goal. -- Best regards, Igor Stasenko.

May 11, 2015

Pharo Screencast By a Ruby Guy

by Sean P. DeNigris

http://devblog.avdi.org/2015/05/11/in-which-i-make-you-hate-ruby-in-7-minut… ----- Cheers, Sean -- View this message in context: http://forum.world.st/Pharo-Screencast-By-a-Ruby-Guy-tp4825891.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

May 11, 2015

Re: [Pharo-dev] Transcript needs your love

by Igor Stasenko

On 11 May 2015 at 23:22, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > Le 11/05/2015 22:27, Igor Stasenko a Ã©crit : > >> On 10 May 2015 at 10:23, stepharo <stepharo(a)free.fr> wrote: >> >> >>> i think there is a fundamental difference between 'stream' and 'update >>> on >>> >>>> the screen' . Choose one and stick to it. >>>>> We shall separate such responsibilities and NEVER ever merge them >>>>> again , >>>>> even if it was cool, nice, soft and puffy in the past. >>>>> Yes, sure, we can then build the facade on top of that providing >>>>> similar >>>>> behavior of what was in the past.. >>>>> >>>>> But if not, then it will always be something that will forever be >>>>> causing >>>>> problem, since it is conceptually wrong and looks like attempt to cross >>>>> breed two different species. >>>>> >>>>> <OT> >>>> I have no particular opinions about Transcsript, but I would like to say >>>> that I am very happy to have Igor back in the >>>> Squeak/Pharo/Cuis/Smalltalk >>>> discussions. I may not agree with everything, but I really appreciate >>>> his >>>> thoughtful perspective. There are a few people whose posts I will always >>>> read, and Igor is one of them. >>>> </OT> >>>> >>>> Thanks Dave. I share the same feelings. >>> >>> Dave >>>> >>>> >>>> >>> Guys, that was completely unnecessary. :) >> >> My problem with transcript was always a multiple layers penetration to get >> things done. >> And Cuis version is good demonstration to that (sorry, Juan): >> - who the heck needs APIs, protocols and overall design rules, if we can >> just cut through things to get to the functionality we need and put things >> one the screen right away without dabbling with Morphic/whatever? >> Because why not? Half of Squeak (and subsequently, Pharo) code is written >> that way anyways.. Following such development style, then i should rewrite >> everything in assembler, make it work blazingly fast, and who are you to >> criticize thing that works well and outperforms everything that ever >> written before? >> Right? >> >> What is broken, needs to be fixed. Who opposed that? >> I just have different than Eliot view on what is broken and consequently, >> what is needed to fix it. >> Note, that i *want* the very same behavior at the end. I want transcript >> that can handle immediate updates on the screen. >> But i want it to be async, and do not impact the performance of the >> system, >> because it is awful, when console output takes 99% of your computation >> resources. >> Sure, it may be cool for VM devs, but have you thought about rest of use >> cases? >> Because there's plenty of them, and not all of them require immediate >> feedback on the screen. >> My 'doctrine' is to have a versatile tool that suits well for many use >> cases, not just one. >> >> P.S. Please note, i said nothing new about Transcript that i wasn't saying >> couple years ago to Stef and to other people i was communicating with.. >> Yeah time runs fast, and not everything you want can be done, but it >> doesn't means that i changed my mind. >> I wonder, how other people feel, when they stating obvious (to their >> thinking), and others look at them as a doctrinal dumbass. That's how i >> feel. :) >> >> > Igor, of course nobody never saw you as a 'doctrinal dumbass' > you are 100% correct on all you said, Elliot is just pragmatic here and > does want to go into > other considerations that would break the workflow he likes and introduce > complexity where there is largely enough, > may be that made him overreacting a little... > this can happen to anybody > > Don't think i am overreacting on Eliot's overreacting whatever.. We're a good friends, and pike fight on mailing list is not gonna change that. I just stating my POV, he stating own.. and that's how i see it, if you remove the giggles :). > If he needs some tools or has some specific requirements that are doable, > why not > trying to give him and Clement even if they are not the bests ? > I see the CuisTranscript as a pragmatic solution that does not change too > much things since vm developement is complex and needs a proven basis, > plus as explained by Clement too sophisticated tools cannot be used > sometimes. > > So, why complaining? Why not just do it. Or do you think i will scream 'over my dead body' or what? If you know how to make it better, do it. I popped-out here mainly to explain the motivation of changes we did,and to point out on the problems we had in the past and shared some insights how i would deal with it. > That said, about Transcript being asynchronous, I fully agree that it > would be be better, but I guess it would also imply some serious changes in > UI process and the World>>doOnecycle concept (that would be good anyway, it > is weird). > I also think my suggestion of asynchronous do-it has some other interests > (exploration of futures in asynchronous processing for example), but I am > not interested in fighting on that, it's overkill here with too much > complexity introduced. > > One thing at a time. I don't think it is too hard to do, or make things overly complex. What is true,is that we got little or no incentive/resources among people, to do that. > :) > > -- > Regards, > > Alain > > > -- Best regards, Igor Stasenko.

May 11, 2015

Re: [Pharo-dev] Transcript needs your love

by Alain Rastoul

Le 11/05/2015 22:27, Igor Stasenko a Ã©crit : > On 10 May 2015 at 10:23, stepharo <stepharo(a)free.fr> wrote: > >> >> i think there is a fundamental difference between 'stream' and 'update on >>>> the screen' . Choose one and stick to it. >>>> We shall separate such responsibilities and NEVER ever merge them again , >>>> even if it was cool, nice, soft and puffy in the past. >>>> Yes, sure, we can then build the facade on top of that providing similar >>>> behavior of what was in the past.. >>>> >>>> But if not, then it will always be something that will forever be causing >>>> problem, since it is conceptually wrong and looks like attempt to cross >>>> breed two different species. >>>> >>> <OT> >>> I have no particular opinions about Transcsript, but I would like to say >>> that I am very happy to have Igor back in the Squeak/Pharo/Cuis/Smalltalk >>> discussions. I may not agree with everything, but I really appreciate his >>> thoughtful perspective. There are a few people whose posts I will always >>> read, and Igor is one of them. >>> </OT> >>> >> Thanks Dave. I share the same feelings. >> >>> Dave >>> >>> >> > Guys, that was completely unnecessary. :) > > My problem with transcript was always a multiple layers penetration to get > things done. > And Cuis version is good demonstration to that (sorry, Juan): > - who the heck needs APIs, protocols and overall design rules, if we can > just cut through things to get to the functionality we need and put things > one the screen right away without dabbling with Morphic/whatever? > Because why not? Half of Squeak (and subsequently, Pharo) code is written > that way anyways.. Following such development style, then i should rewrite > everything in assembler, make it work blazingly fast, and who are you to > criticize thing that works well and outperforms everything that ever > written before? > Right? > > What is broken, needs to be fixed. Who opposed that? > I just have different than Eliot view on what is broken and consequently, > what is needed to fix it. > Note, that i *want* the very same behavior at the end. I want transcript > that can handle immediate updates on the screen. > But i want it to be async, and do not impact the performance of the system, > because it is awful, when console output takes 99% of your computation > resources. > Sure, it may be cool for VM devs, but have you thought about rest of use > cases? > Because there's plenty of them, and not all of them require immediate > feedback on the screen. > My 'doctrine' is to have a versatile tool that suits well for many use > cases, not just one. > > P.S. Please note, i said nothing new about Transcript that i wasn't saying > couple years ago to Stef and to other people i was communicating with.. > Yeah time runs fast, and not everything you want can be done, but it > doesn't means that i changed my mind. > I wonder, how other people feel, when they stating obvious (to their > thinking), and others look at them as a doctrinal dumbass. That's how i > feel. :) > Igor, of course nobody never saw you as a 'doctrinal dumbass' you are 100% correct on all you said, Elliot is just pragmatic here and does want to go into other considerations that would break the workflow he likes and introduce complexity where there is largely enough, may be that made him overreacting a little... this can happen to anybody If he needs some tools or has some specific requirements that are doable, why not trying to give him and Clement even if they are not the bests ? I see the CuisTranscript as a pragmatic solution that does not change too much things since vm developement is complex and needs a proven basis, plus as explained by Clement too sophisticated tools cannot be used sometimes. That said, about Transcript being asynchronous, I fully agree that it would be be better, but I guess it would also imply some serious changes in UI process and the World>>doOnecycle concept (that would be good anyway, it is weird). I also think my suggestion of asynchronous do-it has some other interests (exploration of futures in asynchronous processing for example), but I am not interested in fighting on that, it's overkill here with too much complexity introduced. :) -- Regards, Alain

May 11, 2015

Re: [Pharo-dev] Transcript needs your love

by Igor Stasenko

On 10 May 2015 at 13:57, Ben Coman <btc(a)openinworld.com> wrote: > > not that output is interleaved with a specific policy. > > Hi Eliot, > > I guess it was hard to analyse that output dump from your phone, and I > should have been more explicit. The problem is not the interleave order, > but duplicate and missing output items. I've cut down the example and and > manually reordered the Squeak items to make it easier to see this. > > Transcript clear. > [ $a asciiValue to: $h asciiValue do: [ :c | > [ 1 to: 9 do: [ :i | > Transcript show: c asCharacter printString , i printString , ' '. > Processor yield. > ]. > ] forkAt: 40. > ]. > ] forkAt: 41. > > Squeak 4.5 gives... > $a1 $b1 $b1 $c1 $d1 $e1 $f1 $g1 $h1 > $a2 $b2 $b2 $c2 $d2 $e2 $f2 $g2 $h2 > $a3 $b3 $b3 $c3 $d3 > $b4 $d4 $f4 $g4 $g4 > $b5 $c5 $d5 $d5 $f5 > $a6 $a6 $c6 $d6 $e6 $f6 $g6 $h6 > $a7 $b7 $d7 $d7 $g7 $h7 $f7 > $a8 $a8 $b8 $c8 $c8 $f8 $g8 $h8 $h8 > $b9 $b9 $c9 $e9 $e9 $f9 $f9 $g9 $h9 > > Pharo 50041 gives... > $a1 $b1 $c1 $d1 $e1 $f1 $g1 $h1 > $a2 $b2 $c2 $d2 $e2 $f2 $g2 $h2 > $a3 $b3 $c3 $d3 $e3 $f3 $g3 $h3 > $a4 $b4 $c4 $d4 $e4 $f4 $g4 $h4 > $a5 $b5 $c5 $d5 $e5 $f5 $g5 $h5 > $a6 $b6 $c6 $d6 $e6 $f6 $g6 $h6 > $a7 $b7 $c7 $d7 $e7 $f7 $g7 $h7 > $a8 $b8 $c8 $d8 $e8 $f8 $g8 $h8 > $a9 $b9 $c9 $d9 $e9 $f9 $g9 $h9 > > The Pharo output is untouched (except to insert newlines). Its ordering is > only a side effect of correct behaviour wrt showing *all* output *once > only*. Indeed its only a side effect that the output ordering (presumably) > reflects the actual order that processes were scheduled -- but actually > this is a critical advantage when trying to debug multi-threaded race > conditions. > > cheers -ben > > On Sun, May 10, 2015 at 12:20 AM, Eliot Miranda <eliot.miranda(a)gmail.com> > wrote: > >> Hi Ben, >> >> first, thanks for responding dispassionately to the technical issues. >> >> As far as thread-safety I thought the issue with the transcript was not >> providing some form of protection against unpredictable interleavings of >> output from multiple separate processes, but was just avoiding lock-up. If >> one outputs to another kind of stream (file, terminal window) from multiple >> processes you typically get jumbled output on a first-come first-served >> basis. What one wants IMO is that the transcript remains robust, with no >> red morphs of death, not that output is interleaved with a specific policy. >> >> How you gonna ensure that, when only tool that you have is a completely single-minded (err.. threaded :) ) / thread unsafe Morphic in your hands, that is absolutely dangerous to use outside UI thread and recipe for disaster when fiddling with its state or interrupting it at non-safe point? Red morphs of death is actually a good sign of that, that Morphic has little to offer to those, who dare to use multiple threads. Sometimes i thinking, would it be better to throw away all that multi-threading crafts in VM and image, and make smalltalk *way more* simpler and straight (like many other interpreted languages, that don't have threads).. Because bulk majority 99.999% of our codebase never using/deals with threading anyways. Besides, most of the people finding multi-threading bizarre and confusing.. So, lets just throw it away, no big loss. :) P.S. and i didn't meant to sound passionate, but rather sarcastic :) > Eliot (phone) >> >> -- Best regards, Igor Stasenko.

May 11, 2015

Re: [Pharo-dev] Transcript needs your love

by Igor Stasenko

Speaking about penetrating multiple layers.. Lemme tell you the story: One day, a brave hero (let's call him Stef :) ) decided to save the world... err improve Transcript and make it thread-safe. And everything vent well until he stumbled upon #endEntry logic, because he was unable to figure out how it is handled and where it is handled.. He asked me for help and we sat together and looked for what can be done.. After many months and fierce battles (longer that any developer would except), we finally discovered that #endEntry logic is handled .. (drumroll...) in TextMorph, as a separate case in case-statement in its #changed: method. Sure it was a long ago, and my memory could fail me, i might be completely wrong on some details, and maybe instead we were drinking ale with fairies in the pub, and there was no any fights. But that's what is fairy tale for :) -- Best regards, Igor Stasenko.

May 11, 2015

Re: [Pharo-dev] Lighthouse example throw segfault

by Alejandro Infante

> On May 11, 2015, at 4:43 PM, stepharo <stepharo(a)free.fr> wrote: > > Hi alejandro > > which image? â For the already built image, I used the version of May 9th (Build #467) and is based on Pharo 3 â For the one that I loaded the stable code using the last ConfigurationOf (commit number 13) on a Pharo4.0 image (#40611) > which version? Guess this is answered up there. > which latest vm? Iâm not sure how to get this, sending --version or --help do not work. Even though, comparing the creation date of the file of the VM, I guess that is PharoVM 421.zip from the fileserver. > > do you see a pattern :) 5 minutes ago I tried to using a different vm. Using the PharoS VM (206.zip from the pharo fileserver) I wasnât able to reproduce the error. > > Stef > > Le 11/5/15 20:37, Alejandro Infante a Ã©crit : >> Hello, >> >> When I try to open the image from Jenkins the screen goes black for 5 seconds and then it throws a segmentation fault in my Mac. I use a Macbook air with the latest stable Pharo VM. >> >> Using the ConfigurationOf I have found that Lighthouse by default set the display to work in fullscreen, and is perfectly usable, but when saving the image it is impossible to open it again (segfault). I attached the crash.dmp. >> >> If I try to disable the fullscreen before saving it, the error does not appear again. >> >> Iâm the only one capable to reproduce this? >> >> Cheers, >> Alejandro >> > > Cheers, Alejandro

May 11, 2015