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

Re: [Pharo-dev] Can Monticello version message be a Text?

by Thierry Goubier

Le 09/04/2015 23:34, Yuriy Tymchuk a Ã©crit : > Sad. It happens to me quite a lot. So is this an issue in monticello? I don't know. Something is happening somewhere with the source code, and as a consequence Monticello test for finding the changes mark everything as changed. I'm pushing a solution for that symptom. https://pharo.fogbugz.com/default.asp?15321 But I haven't found the reason. Something is switching the line endings on some of the MC definitions, and I don't know who or what is doing that (and not everytime). Thierry > > > >> On 08 Apr 2015, at 22:13, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> Uko, >> >> you seem to have the same bug Johan is describing. >> >> MC seems to loose the contents of a package working copy, and hence is unable to build a correct diff. >> >> I've seen it happen at times, but rarely enough so I didn't pay attention to it. >> >> Thierry >> >> Le 08/04/2015 09:44, Yuriy Tymchuk a Ã©crit : >>> >>>> On 07 Apr 2015, at 12:16, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>>> >>>> Le 07/04/2015 11:01, Yuriy Tymchuk a Ã©crit : >>>>> Hi, thank you very much for investigating this. >>>> >>>> You're working on it too :) >>>> >>>>> These are the steps to reproduce: >>>>> >>>>> 1. Clone a git repo (e.g. https://github.com/Uko/VnaExporter.git) >>>>> 2. Add it as gitfiletree repo to the pharo image. >>>>> 3. Change something, commit part of the changes with Komitter. >>>>> 4. Change something more. >>>>> 5. Open Komitter, you should see a strange diff. >>>>> 6. Select 1 or 2 methods & commit them. >>>>> 7. Now you should have only 2 methods in your repo. >>>> >>>> I did, and I don't see anything suspicious. Browsing the repository at each step gave me the complete package as expected (minus the unsaved changes, of course). >>>> >>>> Can you show a screenshot at step 5? >>> >>> Iâve done a screen recording https://dl.dropboxusercontent.com/u/83145561/GitKomitter.mov >>> >>> Uko >>> >>>> >>>> Thierry >>>> >>> >>> >>> >> >> > > > >

April 9, 2015

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

by phil＠highoctane.be

No Debug Tests? Geez, I am using that all the time. Phil On Thu, Apr 9, 2015 at 10:21 PM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 09 Apr 2015, at 22:32, Sean P. DeNigris <sean(a)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 9, 2015

Re: [Pharo-dev] Can Monticello version message be a Text?

by Yuriy Tymchuk

Sad. It happens to me quite a lot. So is this an issue in monticello? > On 08 Apr 2015, at 22:13, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Uko, > > you seem to have the same bug Johan is describing. > > MC seems to loose the contents of a package working copy, and hence is unable to build a correct diff. > > I've seen it happen at times, but rarely enough so I didn't pay attention to it. > > Thierry > > Le 08/04/2015 09:44, Yuriy Tymchuk a Ã©crit : >> >>> On 07 Apr 2015, at 12:16, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >>> >>> Le 07/04/2015 11:01, Yuriy Tymchuk a Ã©crit : >>>> Hi, thank you very much for investigating this. >>> >>> You're working on it too :) >>> >>>> These are the steps to reproduce: >>>> >>>> 1. Clone a git repo (e.g. https://github.com/Uko/VnaExporter.git) >>>> 2. Add it as gitfiletree repo to the pharo image. >>>> 3. Change something, commit part of the changes with Komitter. >>>> 4. Change something more. >>>> 5. Open Komitter, you should see a strange diff. >>>> 6. Select 1 or 2 methods & commit them. >>>> 7. Now you should have only 2 methods in your repo. >>> >>> I did, and I don't see anything suspicious. Browsing the repository at each step gave me the complete package as expected (minus the unsaved changes, of course). >>> >>> Can you show a screenshot at step 5? >> >> Iâve done a screen recording https://dl.dropboxusercontent.com/u/83145561/GitKomitter.mov >> >> Uko >> >>> >>> Thierry >>> >> >> >> > >

April 9, 2015

New Cog VMs available

by Eliot Miranda

... at http://www.mirandabanda.org/files/Cog/VM/VM.r3308/. CogVM binaries as per VMMaker.oscog-eem.1178/r3308 Plugins: Integrate Nicolas' fixes that use positiveMachineIntegerFor: for pointers. Newspeak: Print a warning in the method shared under multiple selectors scenario. Implement outer sends as clean sends just like implicit receiver sends. Add ObjectRepresentation>>illegalClassTag and use it for initializing and unlinking implicit and outer sends. Newspeak & Sista: The multiple bytecode set block initial nil counters need to be specific to the bytecode set in effect. Spur: Implement Clement's much better solution for the stale supersend problem. Place code at the send site for super sends to follow stale forwarded receivers. This parallels the interpreter implementation. Beef up the post-become scan of send sites to unlink all send sites that link to an invalid class tag. Cogit: Optimize StackToRegisterMappingCogit>>genReturnReceiver to not load ReceiverResultReg if it already contains self. Revise method map generation to provide multiple send type annotations. Add an IsAnnotationExtension annotation type that implicitly has a zero displacement and uses its displacement bits to extend the preceeding IsSendCall annotation. This allows us to eliminate all the exotic entry-points and keep only the checked and unchecked entries. Change IA32's genPushRegisterArgsForNumArgs: to not smash TempReg now that it is used in directed super send trampolines. Use PushCq to pass small integer constants in the trampolines instead of smashing TempReg, which is now used to hold the directed supersend argument. Add support for PushCq. Could use PushCw but on x86 PushCq is a lot shorter. Mac builds: Use UTC as the timezone for the build timestamp. Using the local timezone doesn't work :(. -- best, Eliot

April 9, 2015

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

by Marcus Denker

> On 09 Apr 2015, at 22:32, Sean P. DeNigris <sean(a)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 9, 2015

Re: [Pharo-dev] broken setting in FFI

by Thierry Goubier

Le 09/04/2015 22:40, stepharo a Ã©crit : > >>> We started to extract tge configuration code out of pillar but we do not >>> know if it will work for settings. >>> So far no time to check. >>> >>> It is called cocoon on pharoextras >> >> Small remark on the documentation on Smalltalkhub: it is STON-based, >> not JSON-based. >> >> Will you make this an item (replace settings by Cocoon) on the roadmap >> for Pharo5? I know I would. > > you mean saving settings with Cocoon? > Not sure because somebody should do it and my plate will quite full Fair enough. But at least could we integrate it in Pharo5 to allow apps to use it? Thierry

April 9, 2015

Re: [Pharo-dev] source code mgmt issues in Pharo4

by Thierry Goubier

Hi Stef, I found where is the last issue. I can correct the symptoms, but I don't know why it happens. Not yet. I'm not sure it covers the previous ones, but it may also be the same. Thierry Le 09/04/2015 22:42, stepharo a Ã©crit : > Hi johan > > I usually attract bugs but not these ones. > - I got debugger freezing > - broken refactoring > but not that ones. I would love to have a way to reproduce it. > > Stef > > > > Le 8/4/15 19:41, Johan Brichau a Ã©crit : >> Hi all, >> >> Over the last week, I started working with Pharo4, mostly to make >> Seaside work cleanly. >> >> On several occasions, I had severe issues with the package management: >> - methods that were changed in a class were not recorded as âchangedâ >> in monticello and were absent from the published package >> - versions of methods disappeared (i.e. no longer accessible in the >> version history of a method) >> - looking at the âchangedâ in Monticello showed all code of the >> package as changed (though only a single method has changed). >> >> This makes working with Pharo4 extremely problematic. I cannot trust >> the source code packaging/publishing and merging anymore. >> >> I cannot discern a scenario that leads to these issues but I do have >> an image right now where I only changed a single method and the entire >> package shows up as âchangedâ. >> >> Anyone experience similar issues? >> >> Johan >> > > > >

April 9, 2015

Re: [Pharo-dev] Magritte = Auto-GT Presentation

by Tudor Girba

You get a GLMMagrittePresentation and if you want to use it in the inspector, you have to define your own extension that uses it. Cheers, Doru On Thu, Apr 9, 2015 at 1:34 PM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > Tudor Girba-2 wrote > > The editor should be provided if you load the > > Glamour-Presentations-Magritte. > > How do I enable a GT-Magritte presentation for my object? They don't seem > to > appear by default... > > > > ----- > Cheers, > Sean > -- > View this message in context: > http://forum.world.st/Magritte-Auto-GT-Presentation-tp4817448p4818551.html > Sent from the Pharo Smalltalk Developers mailing list archive at > Nabble.com. > > -- www.tudorgirba.com "Every thing has its own flow"

April 9, 2015

Re: [Pharo-dev] almost ready to release except for two bugs

by stepharo

Le 9/4/15 16:09, Henrik Johansen a Ã©crit : >> On 09 Apr 2015, at 3:43 , stepharo <stepharo(a)free.fr> wrote: >> >> Esteban >> >> I got a kind of endless loop open a debugger.... but I cannot reproduce it :( > Could it be you were debugging something involving "large" collections? (Say, a 30MB ByteArray ) > inspecting/debugging such objects is impossible with the new tools generates so much overhead you get stuck in GC thrashing hell before they even open... May be I was playing indeed with changes file. > Cmd-Dot to interrupt won't make things better, since the debugger that opens has the same object as self, and would take as long to generate the inspector item. > > I know it's too late for 4.0, but it would be nice if someone with the proper GT skills would look at SequenceableCollection gtInspectorItemsIn: to see if it couldn't be made a bit more efficient, for instance avoiding the whole > display: [ :aCollection | (1 to: self size) collect: [ :index | index -> (self at: index) ] ]; > shenanigans. > > Cheers, > Henry > > >

April 9, 2015

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

by stepharo

Le 9/4/15 08:49, Tudor Girba a Ã©crit : > Hi Stef, > > This Raw view is the result of many debates and negotiations. We can > safely say it was designed by committee. > > As I mentioned before, I think the tree is overkill in this context > and it makes things unnecessarily slow. Totally agree on this one. It defeats the purpose of navigation. To me this is terrible. > But, we will try better for Pharo 5 :) > > Cheers, > Doru > > On Fri, Apr 3, 2015 at 7:23 PM, stepharo <stepharo(a)free.fr > <mailto:stepharo@free.fr>> wrote: > > >> The Playground has inspect on Cmd+Shift+i as requested by you. > > Ok good to know because this is important. > What aboout an help? >> >> 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? > > Esteban told me that it was not freezing when we had to trash the > image. > Just that the machine was slow. To me this is a non answer. > > > If we could get a real raw = basic inspect tabe then we can use GT > and work. > To me the raw tab with an explorer inside is counterproductive: we > can get lost, it is slow, it does not work well with navigation of GT. > >> Cheers, >> Doru >> >> >> >> On Thu, Apr 2, 2015 at 5:30 PM, stepharo <stepharo(a)free.fr >> <mailto:stepharo@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 <http://www.tudorgirba.com> >> >> "Every thing has its own flow" > > > > > -- > www.tudorgirba.com <http://www.tudorgirba.com> > > "Every thing has its own flow"

April 9, 2015