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

Re: [Pharo-dev] Pillar package dependency

by Cyril Ferlicot

Hum.. Do we really need the pillarLineEnding method ? Because if you check that return exaclty the same as the lineEnding method into OSPlateform... Someone know why we have a pillarLineEnding method instead of lineEnding ? On 12 April 2015 at 10:53, stepharo <stepharo(a)free.fr> wrote: > somebody added you apparently. > Is it ok now? > > Stef > > Le 11/4/15 09:43, Johan Brichau a Ã©crit : > >> Hi all, >> >> Can someone give me access to the Pillar repository or fix the issue >> below? >> >> I was trying to play around with Pier3 (which uses Pillar) but immediately >> hit an issue. When loading: >> >> Metacello new >> configuration: 'Pier3'; >> version: #'release3.1'; >> load. >> >> And then opening localhost:8080 pier gives you a DNU on >> MacOSXPlatform>>pillarLineEnding >> >> The issue is that the code of Pillar-Model (which is loaded by Pier) is >> dependent on Pillar-ExporterCore (which contains the method above). >> I think two things need to be done: >> - move the #pillarLineEnding method to the Pillar-Model >> - move the #pillarLineEnding method from Platform class to GRPlatform >> class to ease porting to other Smalltalks >> >> thanks >> Johan >> >> >> >> > > -- Cheers Cyril Ferlicot

April 12, 2015

Re: [Pharo-dev] Can't Log In to CI

by Sven Van Caekenberghe

> On 12 Apr 2015, at 12:43, Max Leske <maxleske(a)gmail.com> wrote: > > >> On 12 Apr 2015, at 04:08, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> >> Did something change in the last 12 hours? > > Confirmed. Canât log in either. Me neither > I get > > Invalid login information. Please try again. > Try again > If you are a system administrator and suspect this to be a configuration problem, see the server console output for more details. > > >> >> >> >> ----- >> Cheers, >> Sean >> -- >> View this message in context: http://forum.world.st/Can-t-Log-In-to-CI-tp4819109.html >> Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >> > >

April 12, 2015

Re: [Pharo-dev] Can't Log In to CI

by Max Leske

> On 12 Apr 2015, at 04:08, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Did something change in the last 12 hours? Confirmed. Canât log in either. I get Invalid login information. Please try again. Try again If you are a system administrator and suspect this to be a configuration problem, see the server console output for more details. > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Can-t-Log-In-to-CI-tp4819109.html > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. >

April 12, 2015

Re: [Pharo-dev] [Pharo-fuel] Binding semantics of SystemDictionary

by Max Leske

> On 10 Apr 2015, at 11:28, Guillermo Polito <guillermopolito(a)gmail.com> wrote: > > Hmm, there is something that I'm missing: > > do you have a real case where fuel is failing? :) No :) But itâs something that has the potential to fail at any time. > > if so, I'd focus on that: where does it come from, how was that class created, maybe it's a very specific case that you can handle in an ad-hoc way (and then leave fuel as it is right nowâ¦) Thatâs why I suggested signalling an exception. It wouldnât change anything about Fuel. But in case someone encounters the problem, Fuel will fail early (during serialization) instead of (very) late (during materialization). Cheers, Max > > El vie., 10 de abr. de 2015 a la(s) 11:24 a. m., Max Leske <maxleske(a)gmail.com <mailto:maxleske@gmail.com>> escribiÃ³: >> On 07 Apr 2015, at 13:30, vm-dev-request(a)lists.squeakfoundation.org <mailto:vm-dev-request@lists.squeakfoundation.org> wrote: >> >> Hmm, I think we are mixing stuff here ^^ >> >> Method Dictionaries and system dictionary accept any object as keys. >> >> To execute code, the VM only checks for identity (+ identity hash that does >> not change) in method dictionaries. The VM never looks up in the system >> dictionary. >> Actually the VM does not make any assumption on the objects you put as >> keys. This makes the VM simpler. >> Then tools enforce that we put there symbols as keys in both. But, we could >> put anything we would like. > > Interesting. > >> >> So, answering your questions: >> >> 1. Are bindings with keys that are not ByteString or ByteSymbol valid? >> >> Theoretically yes, but nobody uses this for real for now. Camille has >> some prototypes that uses this to enforce modularity. >> >> 2. Should we keep allowing ByteString as keys to globals (ByteSymbol >> guarantees identity)? >> >> Well, usually the tools will make sure that you transform them to a >> symbol before. >> >> 3. If we allow ByteString, do we also allow WideString? >> >> Any object ^^ >> >> 4. Would âtype checksâ on SystemDictionary incur a big performance penalty? >> >> Maybe, but not only that. It makes the code more messy also, and >> hardcode tool assumptions. I don't put any type checks in any of my code >> usually, why start there... We should fix fuel to not make that assumption >> instead I think. > > > I agree. I donât like type checks. Just wanted to have talked about the option. > > Thanks for your input Guille. Iâm still not sure how to solve this issue for Fuel though. I see several options: > - signal an exception when the key to a global is not a symbol > - simply serialize a string representation of the key, which will lead to a lookup failure on materialization - > not good > - serialize the identityHash of the key. The identity hash of a symbol is stable across different images and VMs but not across Squeak and Pharo -> not good > - serialize the actual key. This requires us to rewrite the global handling logic and it will once again break backwards compatibility. This might be something for the future. > > So maybe we should: > 1. signal an exception -> no change for users > 2. In a future version rewrite the global handling logic to allow for arbitrary global keys. > > Opinions? > > Cheers, > Max > _______________________________________________ > Pharo-fuel mailing list > Pharo-fuel(a)lists.gforge.inria.fr <mailto:Pharo-fuel@lists.gforge.inria.fr> > http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel <http://lists.gforge.inria.fr/cgi-bin/mailman/listinfo/pharo-fuel>

April 12, 2015

Re: [Pharo-dev] Can't Log In to CI

by Marcus Denker

> On 12 Apr 2015, at 04:08, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > > Did something change in the last 12 hours? > > not that I know Marcus

April 12, 2015

Re: [Pharo-dev] why we removed debugTest from nautilus?

by Marcus Denker

> > I think break points were done by Clara Allende. As far as I know, they work but there's no IDE support for them. I think they are not ready for this release but I am not sure about the status. Marcus can confirm it will not be ready. > > For this release the intention was reviewing and integrating the Reflectivity machinery, and then afterwards the breakpoints. > So far Marcus has done a lot on that part (reviewing and enhancing my prototype for reflectivity), and we have discussed that the breakpoints (in the state I've left them at the end of my internship) should work out of the box. Nevertheless, I want to do a pass on them and update what's necessary once Pharo4 is released. > > But they won't be integrated in the release, that's for sure, because there's work to do with them... > > The problem is that it needs compiler changes that will not be done for Pharo4. Maybe we can back port, but the priority for me is not Pharo4 for this. Marcus

April 12, 2015

Re: [Pharo-dev] why we removed debugTest from nautilus?

by Marcus Denker

> On 11 Apr 2015, at 10:10, Nicolai Hess <nicolaihess(a)web.de> wrote: > > > > 2015-04-10 17:28 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>>: > Well I guess I used to click proceed and not close the debugger... > > > I don't know who is working on the breakpoint support and I don't know how long it will take. > Maybe we can fix thie image freeze and re-include the debugtest code until the new breakpoint support. > > what do you think? > Breakpoints are for Pharo5â¦ maybe back porting will be possible, but it is not the priority. Marcus

April 12, 2015

Re: [Pharo-dev] Add MetaRepoForPharo40 to default repository group

by stepharo

We could now MC logic will query in permanence this extra repo when doing any merge. Stef Le 6/4/15 12:21, Sean P. DeNigris a Ã©crit : > Sven Van Caekenberghe-2 wrote >> 'Define Repository in MC'... just for that. > Ah! Cool. I wondered what those were for. Much easier than typing the URL > in. But why require that at all? The inbox is in the MC working copy browser > by default, why not the MetaRepo? > > > > ----- > Cheers, > Sean > -- > View this message in context: http://forum.world.st/Add-MetaRepoForPharo40-to-default-repository-group-tp… > Sent from the Pharo Smalltalk Developers mailing list archive at Nabble.com. > >

April 12, 2015

Re: [Pharo-dev] Pillar package dependency

by stepharo

somebody added you apparently. Is it ok now? Stef Le 11/4/15 09:43, Johan Brichau a Ã©crit : > Hi all, > > Can someone give me access to the Pillar repository or fix the issue below? > > I was trying to play around with Pier3 (which uses Pillar) but immediately hit an issue. When loading: > > Metacello new > configuration: 'Pier3'; > version: #'release3.1'; > load. > > And then opening localhost:8080 pier gives you a DNU on MacOSXPlatform>>pillarLineEnding > > The issue is that the code of Pillar-Model (which is loaded by Pier) is dependent on Pillar-ExporterCore (which contains the method above). > I think two things need to be done: > - move the #pillarLineEnding method to the Pillar-Model > - move the #pillarLineEnding method from Platform class to GRPlatform class to ease porting to other Smalltalks > > thanks > Johan > > > >

April 12, 2015

Re: [Pharo-dev] why we removed debugTest from nautilus?

by stepharo

Hi nicolai I do not know the complexity of the fix and its addition. I have the impression that we will have more fixes after the release than in 3.0. So prepare it because it can always be used either in 4.0 or 5.0 alpha. Even if at the end we remove it because of better wy to express breakpoint. In france we say "never free the prey for its shadow" ;) Stef Le 11/4/15 14:58, Ben Coman a Ã©crit : > I miss it. I think I remember that a <Restart> <Close> would work, so > a hack fix could be the do a restart when the close button is pushed. > Reintroducing it with the problem fixed would be welcome. > cheers -ben > > On Sat, Apr 11, 2015 at 4:10 PM, Nicolai Hess <nicolaihess(a)web.de > <mailto:nicolaihess@web.de>> wrote: > > > > 2015-04-10 17:28 GMT+02:00 ClÃ©ment Bera <bera.clement(a)gmail.com > <mailto:bera.clement@gmail.com>>: > > Well I guess I used to click proceed and not close the debugger... > > > > I don't know who is working on the breakpoint support and I don't > know how long it will take. > Maybe we can fix thie image freeze and re-include the debugtest > code until the new breakpoint support. > > what do you think? > > > 2015-04-10 1:24 GMT-07:00 Max Leske <maxleske(a)gmail.com > <mailto:maxleske@gmail.com>>: > > For a little more context: the issue was originally raised > by Clara in the thread titled "MNU: receiver of > "stepToCallee:" is nilâ. IIRC the issue was easily > reproducible when debugging a test, then closing the > debugger (via the close icon). Clicking âProceedâ on the > other hand gracefully terminated the process. > > Cheers, > Max > > >> On 10 Apr 2015, at 09:56, Nicolai Hess >> <nicolaihess(a)web.de <mailto:nicolaihess@web.de>> wrote: >> >> 2015-04-10 2:37 GMT+02:00 ClÃ©ment Bera >> <bera.clement(a)gmail.com <mailto:bera.clement@gmail.com>>: >> >> I was using it frequently too and I have never >> experienced any issues... >> >> >> Ok, can you describe a use case, what test case you can >> start and >> close the debugger without image freeze? >> >> Maybe we can find what is the difference between that >> test case and those that freeze the image, and than find >> a fix. >> >> >> 2015-04-09 14:58 GMT-07:00 Nicolai Hess >> <nicolaihess(a)web.de <mailto:nicolaihess@web.de>>: >> >> >> 2015-04-09 23:38 GMT+02:00 phil(a)highoctane.be >> <mailto:phil@highoctane.be> <phil(a)highoctane.be >> <mailto:phil@highoctane.be>>: >> >> No Debug Tests? >> >> Geez, I am using that all the time. >> >> >> And you're never encountered this issue14689 >> <https://pharo.fogbugz.com/default.asp?14689>? >> Or did this work in older versions? >> >> >> >> Phil >> >> >> On Thu, Apr 9, 2015 at 10:21 PM, Marcus >> Denker <marcus.denker(a)inria.fr >> <mailto:marcus.denker@inria.fr>> wrote: >> >> >> > On 09 Apr 2015, at 22:32, Sean P. >> DeNigris <sean(a)clipperadams.com >> <mailto:sean@clipperadams.com>> wrote: >> > >> > Nicolai Hess wrote >> >> >> http://forum.world.st/do-we-need-to-debug-testmethods-from-within-Nautilus-… >> > >> > Ah, I miss that too! From that thread, >> it seems it was removed temporarily >> > until we have real breakpoints. Is >> there an issue for its return? >> > >> >> Not yet. >> >> Marcus >> >> >> >> >> > > > >

April 12, 2015