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

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

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

by phil＠highoctane.be

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 > >

April 2, 2015

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

by Anne Etien

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] Can we have basicRaw in GTInspector?

by Andrei Chis

Yes, we know about this slowness. It comes from the auto-refresh feature. Currently refreshing a tree presentation in Glamour is slow. We tried to get it faster but I do not think we can do it until the release. How many people do use this feature? Should it be enabled by default? We can add a toggle button in the inspector to enable/disable refresh, per inspector window. Cheers, Andrei On Thu, Apr 2, 2015 at 5:51 PM, Cyril Ferlicot <cyril.ferlicot(a)gmail.com> wrote: > Yeah. > We was checking the CCMockConfiguration>>#mockProperty for Cocoon and if > we go litteral4 -> 1 -> keyword > here that freez a lot. > And if you try to open something else you can put your image on the trash. > > On 2 April 2015 at 17:30, 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 >> >> > > > -- > Cheers > Cyril Ferlicot >

April 2, 2015

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

by Max Leske

> 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 ] > > Peter

April 2, 2015

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

by Cyril Ferlicot

Yeah. We was checking the CCMockConfiguration>>#mockProperty for Cocoon and if we go litteral4 -> 1 -> keyword here that freez a lot. And if you try to open something else you can put your image on the trash. On 2 April 2015 at 17:30, 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 > > -- Cheers Cyril Ferlicot

April 2, 2015