- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Brand new modern Spotter design!

by Stephan Eggermont

On 01/04/15 11:53, Tudor Girba wrote: > Nah, you have to experience it first hand yourself. It's too cool to > experience it via a dead picture. On wednesday we used it in the devnology workshop. It just works, no participants had any remarks :) Stephan

April 3, 2015

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

by Tudor Girba

Ok :) Doru On Thu, Apr 2, 2015 at 9:55 PM, phil(a)highoctane.be <phil(a)highoctane.be> wrote: > > > On Thu, Apr 2, 2015 at 9:26 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> 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. >> > > I am on 3.0 and there is for sure a ton of fixes in 4.0 already. > So, I have to live with what I do have there (e.g. No Spotter yet). > > Need to vent after having a couple of image freezes when under pressure. > > Nothing to worry about. > > Phil > >> >> 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" >> > > > > > > > -- www.tudorgirba.com "Every thing has its own flow"

April 3, 2015

Re: [Pharo-dev] FileUrl: Removal Rationale

by Sean P. DeNigris

Sven Van Caekenberghe-2 wrote > Having subclasses for each scheme is hard to maintain (there are hundreds > of schemes)... It also makes little sense implementation wise. Iâm not understanding. For one thing, in Core, weâre not interested in all of the hundreds of schemes but just the few most common (http, file) - although users interested in the specifics of other schemes could easily add those subclasses in their apps. Since subclassing is just a way to share code, wouldnât a ZnFileUrl merely consist of exactly the methods weâre talking about - but more simply implemented? For one thing, it seems it would make extension easier. If I wanted to handle FileUrls and HttpUrls polymorphically with separate classes, no problem - implement two methods. But as it is now, IIUC I have to either implement two operation classes or have a method with a budding switch statement. Also, IMHO implementing a custom multiple dispatch seems exotic enough (i.e. takes extra effort to understand) to require a large benefit to justify. My 2c ----- Cheers, Sean -- View this message in context: http://forum.world.st/FileUrl-Removal-Rationale-tp4816536p4817064.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 2, 2015

New CogVMs available...

by Eliot Miranda

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3306. CogVM binaries as per VMMaker.oscog-eem.1155/r3306 Retract the decision to type the results of the bitwise operators as unsigned; it broke at least the BitBlt plugin. Integrate primitiveIsBigEnder & Nicolas' fix for safer primitiveAdoptInstance & primitiveScanCharacters Mark relevant feature test methods in CogAbstractInstruction as <inline: true>. Spur: Make sure that all stacked values are followed in CoInterpreter>> makeBaseFrameFor: for stale self refs in super sends. Make sure the stack is scanned after a pin operation that involves forwarding. Make sure that the unforwarding stack scan post-become (or post-pin) scans all of the stack contents in the CoInterpreter, since super sends have no read barrier. Mark copyToOldSpace:bytes:format: as not to be inlined so as to avoid impacting copyAndForward's icache density. Newspeak: Add Ryan's new self-send bytecodes. Use NSSendCache for IRC representation. -- best, Eliot

April 2, 2015

Re: [Pharo-dev] Bloc Roadmap

by Sean P. DeNigris

> if you can collect the answers to your question and put them into the pillar doc :), this can help. Awwâ¦ you guessed my plan ;) ----- Cheers, Sean -- View this message in context: http://forum.world.st/Bloc-Roadmap-tp4816171p4817050.html Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com.

April 2, 2015

Re: [Pharo-dev] FileUrl: Removal Rationale

by Sven Van Caekenberghe

Hi Sean, You are right that ZnUrl unifies all schemes in one object class. Something called ZnUrlOperation exists and is used to dispatch named operations on multiple conditions, the scheme, some arguments, but potentially any aspect of a URL. Having subclasses for each scheme is hard to maintain (there are hundreds of schemes) and is only one dimension of looking at URLs. It also makes little sense implementation wise. The #asFileReference implementation does indeed have a hard test inside it, but it is in essence correct: you can only do the conversion is that particular case. I am not saying that the way things are today is the final answer to URL implementation, maybe things can be improved. But what we have now covers a lot of ground (usage scenarios). BTW, Xtreams' #reading, #writing & #appending could also make sense for non-file URLs ... Sven > On 01 Apr 2015, at 04:19, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > I guess FileUrl has been subsumed by ZnUrl. The problem is that the fact that > a URL points to a file is part of it's type. Now there is the ugly: > ZnUrl>>#asFileReference > ... > self assert: self scheme = #file description: 'Only a file:// URL can be > converted to a FileReference'. > > Also Xtreams had FileUrl #reading, #writing, #appending, which also don't > make sense in their current implementations for non-file URLs. > > Suggestions? Comments? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/FileUrl-Removal-Rationale-tp4816536.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

April 2, 2015

Re: [Pharo-dev] Playground opening issue

by Jigyasa Grover

Hi ! It works for me too :) I checked it in Pharo4.0 (Latest update: #40592) Thanks On Fri, Apr 3, 2015 at 1:30 AM, Franck Warlouzet < franck.warlouzet(a)hotmail.fr> wrote: > Nice it works, thank you ! > > Cheers, > Franck > > ------------------------------ > Date: Thu, 2 Apr 2015 21:34:11 +0200 > From: tudor(a)tudorgirba.com > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] Playground opening issue > > > 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] Failing VM tests

by ClÃ©ment Bera

Probably the last merge from Eliot branch introduced bugs. Only latest VM is bugged, not stable. Maybe it's a bug on Eliot's branch that will be fixed soon by him, maybe it's a merge bug. Depends on what you call important. 2015-04-02 12:14 GMT-07:00 Nicolai Hess <nicolaihess(a)web.de>: > 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] Playground opening issue

by Franck Warlouzet

Nice it works, thank you ! Cheers, Franck Date: Thu, 2 Apr 2015 21:34:11 +0200 From: tudor(a)tudorgirba.com To: pharo-dev(a)lists.pharo.org Subject: Re: [Pharo-dev] Playground opening issue Ok. A fix is committed: Name: GT-Playground-TudorGirba.102Author: TudorGirbaTime: 2 April 2015, 9:32:45.226868 pmUUID: 4f8af56e-4904-443d-8e04-2d4e464efc22Ancestors: 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] Can we have basicRaw in GTInspector?

by phil＠highoctane.be

On Thu, Apr 2, 2015 at 9:26 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > 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. > I am on 3.0 and there is for sure a ton of fixes in 4.0 already. So, I have to live with what I do have there (e.g. No Spotter yet). Need to vent after having a couple of image freezes when under pressure. Nothing to worry about. Phil > > 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