- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Playground opening issue

by Tudor Girba

Ok. A fix is committed: Name: GT-Playground-TudorGirba.102 Author: TudorGirba Time: 2 April 2015, 9:32:45.226868 pm UUID: 4f8af56e-4904-443d-8e04-2d4e464efc22 Ancestors: GT-Playground-AndreiChis.101 15281 Playground opening issue do not react on minimization Cheers, Doru On Thu, Apr 2, 2015 at 9:28 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > This is a fun one. I will take a look. > > Cheers, > Doru > > On Thu, Apr 2, 2015 at 3:31 PM, Franck Warlouzet < > franck.warlouzet(a)hotmail.fr> wrote: > >> I opened a Fogbugz entry : >> >> https://pharo.fogbugz.com/f/cases/15281/Playground-opening-issue >> >> ------------------------------ >> From: franck.warlouzet(a)hotmail.fr >> To: pharo-dev(a)lists.pharo.org >> Date: Thu, 2 Apr 2015 15:26:31 +0200 >> Subject: [Pharo-dev] Playground opening issue >> >> >> Hello, >> >> Open a new Playground when one of the others is already opened is ok, but >> if all of the Playgrounds are minimalized, the new one will be opened very >> very small (Too small to be used). >> >> Cheers, >> Franck >> > > > > -- > www.tudorgirba.com > > "Every thing has its own flow" > -- www.tudorgirba.com "Every thing has its own flow"

April 2, 2015

Re: [Pharo-dev] Playground opening issue

by Tudor Girba

This is a fun one. I will take a look. Cheers, Doru On Thu, Apr 2, 2015 at 3:31 PM, Franck Warlouzet < franck.warlouzet(a)hotmail.fr> wrote: > I opened a Fogbugz entry : > > https://pharo.fogbugz.com/f/cases/15281/Playground-opening-issue > > ------------------------------ > From: franck.warlouzet(a)hotmail.fr > To: pharo-dev(a)lists.pharo.org > Date: Thu, 2 Apr 2015 15:26:31 +0200 > Subject: [Pharo-dev] Playground opening issue > > > Hello, > > Open a new Playground when one of the others is already opened is ok, but > if all of the Playgrounds are minimalized, the new one will be opened very > very small (Too small to be used). > > Cheers, > Franck > -- www.tudorgirba.com "Every thing has its own flow"

April 2, 2015

Re: [Pharo-dev] Can we have basicRaw in GTInspector?

by Tudor Girba

Hi Phil, I think this is just not constructive at all to have a private club like that and not tell us about it. Please take a look at the reply of Andrei. Cheers, Doru On Thu, Apr 2, 2015 at 6:16 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > Welcome to the club of GT is awesome and sometimes freezes it all. > > Happened to me once or twice this morning as well. > Switched back to basic inspector for a couple things. > > Having both options available would be nice (like inspect = basic /explore > = gt). > > Phil > > On Thu, Apr 2, 2015 at 5:30 PM, stepharo <stepharo(a)free.fr> wrote: > >> This morning GTInspector was so slow that it blocked the complete system >> on the machine of Cyril. :( >> We can tell him that he is stupid to have a bad machine or we could try >> to use this to see how >> we can help our users. >> >> So we had to use basicInspect to get our job done (once we ctrl-. to >> escape the render hell) >> because raw uses a tree morph. >> >> Why raw cannot reproduce the old simple and working basicInspect >> then we could have a "basic" inspect on double click to avoid to use this >> bad tree and that we can work. >> >> just try to on RubSmalltalkCodeMode class>>#menuOn: to get the feel. Even >> on my superfast machine is >> is sluggish. >> >> I really think that we should support backdoors. >> We need to have a mini browser, a mini debugger and a working inspector. >> >> Setf >> >> > > > > > -- www.tudorgirba.com "Every thing has its own flow"

April 2, 2015

Re: [Pharo-dev] Can we have basicRaw in GTInspector?

by Tudor Girba

The Playground has inspect on Cmd+Shift+i as requested by you. There is a problem with the update as it does not scale in the current form. Please see the reply of Andrei. We will likely remove that feature for the release. Just to clarify: When did we ever say that someone is stupid? Cheers, Doru On Thu, Apr 2, 2015 at 5:30 PM, stepharo <stepharo(a)free.fr> wrote: > This morning GTInspector was so slow that it blocked the complete system > on the machine of Cyril. :( > We can tell him that he is stupid to have a bad machine or we could try to > use this to see how > we can help our users. > > So we had to use basicInspect to get our job done (once we ctrl-. to > escape the render hell) > because raw uses a tree morph. > > Why raw cannot reproduce the old simple and working basicInspect > then we could have a "basic" inspect on double click to avoid to use this > bad tree and that we can work. > > just try to on RubSmalltalkCodeMode class>>#menuOn: to get the feel. Even > on my superfast machine is > is sluggish. > > I really think that we should support backdoors. > We need to have a mini browser, a mini debugger and a working inspector. > > Setf > > -- www.tudorgirba.com "Every thing has its own flow"

April 2, 2015

Failing VM tests

by Nicolai Hess

Anyone knows why the vm tests on the build server are failing? https://ci.inria.fr/pharo/view/4.0-VM/job/PharoVM-tests/lastCompletedBuild/… is this importan? nicolai

April 2, 2015

Re: [Pharo-dev] [Vm-dev] Re: Status of Pharo VM for FreeBSD

by Eliot Miranda

Hi Andreas, On Sun, Mar 15, 2015 at 12:23 PM, Andreas Wacknitz <A.Wacknitz(a)gmx.de> wrote: > > Hi Eliot, > > as promised I checked what I did and found something I changed: > > The file platforms/unix/vm/sqUnixHeartbeat.c has the function void > ioUpdateVMTimezone(). > It was changed to something similar to what is in Cog's > sqUnixITimerHeartbeat.c: > > void > ioUpdateVMTimezone() > { > updateMicrosecondClock(); > #ifdef HAVE_TM_GMTOFF > time_t utctt; > utctt = (get64(utcMicrosecondClock) - > MicrosecondsFrom1901To1970) > / MicrosecondsPerSecond; > vmGMTOffset = localtime(&utctt)->tm_gmtoff * > MicrosecondsPerSecond; > #else > # ifdef HAVE_TIMEZONE > extern time_t timezone, altzone; > extern int daylight; > vmGMTOffset = -1 * (daylight ? altzone : timezone) * > MicrosecondsPerSecond; > # else > # error "cannot determine timezone correction" > # endif > #endif > } > > One thing is striking: the call to updateMicrosecondClock() is here before > the #ifdef HAVE_TM_GMTOFF while > in sqUnixITimerHeartbeat.c it is after the #ifdef. > Ah OK. Thanks! > I don't know which one is correct (I may have copied it wrongly from > sqUnixITimerHeartbeat). > Albeit the one here seems to be correct in my eyes. What do you think? > I think you're absolutely right. I'l make the change. > (Side note: As far as I remember Solaris does not have tm_gmtoff and thus > the else part is being executed). > > > Regards > Andreas > thanks, and welcome! > > Am 14.03.15 18:33, schrieb Andreas Wacknitz: > > Hi Eliot, > > Am 11.03.2015 um 23:15 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > > HI Andreas, > > On Wed, Mar 11, 2015 at 9:55 AM, Andreas Wacknitz <a.wacknitz(a)gmx.de> > wrote: > >> >> Hi Clement, >> >> Am 11.03.2015 um 09:23 schrieb ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >> Hello, >> >> About the FreeBSD VM, Holger Freyther worked on it so he's the best >> person to answer. I think some people used it and it was at least partially >> working. >> >> Thatâs my impression. The VMMaker contains some FreeBSD classes but I >> have the impression that they are not complete (and probably outdated). >> >> >> About your NativeBoost bug on openSolaris, need more information: >> >> - Can you confirm that you use an intel processor on your openSolaris >> machine ? I assume that yes but I ask because solaris were typically >> running on other processors. NativeBoost, as of today, works only with >> intel processor. >> >> Yes, my Sun Ultra 24 is an Intel based Workstation (Q9300). >> >> - Do you build the Cog VM or Stack VM ? I mean PharoVMBuild or >> PharoSVMBuild ? I think the PharoSVMBuild does not include NativeBoost by >> default, that may be your problem. There's a fix somewhere... >> >> PharoVM from "branch 'master' of >> https://github.com/pharo-project/pharo-vm" (thus Cog VM). >> > > I would like to fold back any changes into the svn master repository for > Cog. What are the diffs? (If you have time to send me the diffs that > would save me a lot of time). > > I donât know whether there is much to harvest from what I did. As far as I > remember most of my work was hacking the generator image created by the > pharo vm scripts (for my Mac) in order to make > the resulting C code to compile under openindiana. The basis for Solaris > was already there (and as far as I can see it is also in the Squeak VM > sources). I only tweaked some definitions and includes. > I will look at my notes tomorrow and will post if I will find something > relevant. > > I am curios about the future of the PharoVM. The main development of the > VM seem to happen in the SqueakVM (by you). Getting the Spur changes into > the PharoVM seem to be a lot of work. > Wouldnât it be better to move back the changes of the PharoVM into the > SqueakVM and have a united development? > And what is the status and what are the plans regarding Timothyâs > (gettimothy) work? > > Regards > Andreas > > > > -- best, Eliot

April 2, 2015

Re: [Pharo-dev] [Vm-dev] Re: Status of Pharo VM for FreeBSD

by Eliot Miranda

Hi Andreas, sorry to be late in replying. This has been a busy month (I moved house). On Sat, Mar 14, 2015 at 10:33 AM, Andreas Wacknitz <a.wacknitz(a)gmx.de> wrote: > > Hi Eliot, > > Am 11.03.2015 um 23:15 schrieb Eliot Miranda <eliot.miranda(a)gmail.com>: > > HI Andreas, > > On Wed, Mar 11, 2015 at 9:55 AM, Andreas Wacknitz <a.wacknitz(a)gmx.de> > wrote: > >> >> Hi Clement, >> >> Am 11.03.2015 um 09:23 schrieb ClÃ©ment Bera <bera.clement(a)gmail.com>: >> >> Hello, >> >> About the FreeBSD VM, Holger Freyther worked on it so he's the best >> person to answer. I think some people used it and it was at least partially >> working. >> >> Thatâs my impression. The VMMaker contains some FreeBSD classes but I >> have the impression that they are not complete (and probably outdated). >> >> >> About your NativeBoost bug on openSolaris, need more information: >> >> - Can you confirm that you use an intel processor on your openSolaris >> machine ? I assume that yes but I ask because solaris were typically >> running on other processors. NativeBoost, as of today, works only with >> intel processor. >> >> Yes, my Sun Ultra 24 is an Intel based Workstation (Q9300). >> >> - Do you build the Cog VM or Stack VM ? I mean PharoVMBuild or >> PharoSVMBuild ? I think the PharoSVMBuild does not include NativeBoost by >> default, that may be your problem. There's a fix somewhere... >> >> PharoVM from "branch 'master' of >> https://github.com/pharo-project/pharo-vm" (thus Cog VM). >> > > I would like to fold back any changes into the svn master repository for > Cog. What are the diffs? (If you have time to send me the diffs that > would save me a lot of time). > > I donât know whether there is much to harvest from what I did. As far as I > remember most of my work was hacking the generator image created by the > pharo vm scripts (for my Mac) in order to make > the resulting C code to compile under openindiana. The basis for Solaris > was already there (and as far as I can see it is also in the Squeak VM > sources). I only tweaked some definitions and includes. > I will look at my notes tomorrow and will post if I will find something > relevant. > > I am curios about the future of the PharoVM. The main development of the > VM seem to happen in the SqueakVM (by you). Getting the Spur changes into > the PharoVM seem to be a lot of work. > Note that this will happen (or is already happening). Esteban is working on building the Spur version of Pharo, so he is doing this work. But actually it *isn't* that much work. There is basically a trio of new memory management files for each platform, e.g. platforms/unix/vm/sqUnixSpurMemory.c, and a new source tree for the spur vm, spursrc/vm. The system is already set up to build multiple VMs (at least the svn tree is). > Wouldnât it be better to move back the changes of the PharoVM into the > SqueakVM and have a united development? > Well, I don't think the Pharo community will be willing to move to svn. SOme time I may be able to move to git. But yes, I *would* like to see important fixes merged back into the SqueakVM. I think this is very important. I'm too overloaded to look at the pharovm so I'm dependent on those working on the pharovm in giut to send me changes for integration. And what is the status and what are the plans regarding Timothyâs > (gettimothy) work? > > Regards > Andreas > > > -- best, Eliot

April 2, 2015

Re: [Pharo-dev] (a = b) ifTrue: []

by ClÃ©ment Bera

Basically ifTrue: aBlock is equivalent to: ifTrue: aBlock ifFalse: [ ] This is why ifTrue: answers nil if the receiver is false, because the evaluation of an empty block answers nil ( [ ] is the same thing as [ nil ] ). So you have to write it explicitly. The #and: version is probably the best :-). 2015-04-02 9:12 GMT-07:00 Anne Etien <anne.etien(a)univ-lille1.fr>: > > Le 2 avr. 2015 Ã 18:02, Max Leske <maxleske(a)gmail.com> a Ã©crit : > > > On 02 Apr 2015, at 17:31, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > ^ (a=b) ifTrue: [ aBlockCheckingConditions]. > > > Boolean is still just an object, so you can use a cascade > ^ (a=b) > ifTrue: [ aBlockCheckingConditions]; > yourself > > > But that will always return the the boolean from the first statement! If > you want to return something from the conditions block you canât do that. > > An alternative might be > > ^ a = b and: [ condition ] > > > Yes!! Good idea. > Thanks. > Anne > > > > Peter > > > >

April 2, 2015

Re: [Pharo-dev] (a = b) ifTrue: []

by kilon alios

its possible to completely or partly avoid a condition check . Instead you can use a common name for a method for various objects , that method may have different code for each object it belongs. This way you dont need to check your data instead you send the message and you let the method itself to execute the appropriate code for the approriate object( kind of data). This also much more reasonable to read. It will depend however in your particular situation. You can have also a chain of methods. Essentially we talk here about objects that interact with each other by triggering methods without the need for conditional checks since the method call is of the same name but the code executed depends on the receiver of the message / messages. It takes time to get used to this chain reaction message sending but I think it really worth it because it produces far simpler code to read and far more modular too. On Thu, Apr 2, 2015 at 6:15 PM, Anne Etien <anne.etien(a)univ-lille1.fr> wrote: > Hi, > > I wanted to write a method that: > - if (a = b) checks other conditions that are specified in the ifTrue > block and return this (boolean) value > - returns false if (a!=b) > > So I wrote: > myMethod > ^ (a=b) ifTrue: [ aBlockCheckingConditions]. > > However, when (a!=b) the method returns nil (since false ifTrue: [] > returns nil). So do you have an idea how I can do to express that or should > I mandatorily wrote also an ifFalse:? > > The problem comes certainly because we donât know that the ifTrueBlock > will return a boolean. > > If you have prettier ideas, I am interested in. > > Anne >

April 2, 2015

Re: [Pharo-dev] (a = b) ifTrue: []

by Peter UhnÃ¡k

On Thu, Apr 2, 2015 at 6:02 PM, Max Leske <maxleske(a)gmail.com> wrote: > > On 02 Apr 2015, at 17:31, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > > ^ (a=b) ifTrue: [ aBlockCheckingConditions]. > > > Boolean is still just an object, so you can use a cascade > ^ (a=b) > ifTrue: [ aBlockCheckingConditions]; > yourself > > > But that will always return the the boolean from the first statement! > Ah, I've misread the question. Peter

April 2, 2015