February 2016 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Spec Experience in Need for Feedback :)

by Nicolai Hess

2016-02-08 15:02 GMT+01:00 Thierry Goubier <thierry.goubier(a)gmail.com>: > > > 2016-02-08 11:31 GMT+01:00 Nicolai Hess <nicolaihess(a)gmail.com>: > >> >> >> 2016-02-08 10:37 GMT+01:00 stepharo <stepharo(a)free.fr>: >> >>> Hi guys >>> >>> I should say that I'm sick (gift from my little boy) so may be this is >>> obvious. >>> >>> I'm looking at the code of Spec and I hate this code :) >>> >>> widgetDo: aBlock >>> >>> ^ self widget ifNotNil: aBlock >>> >>> >>> I do not see why widgetDo: has to test for nil >>> So I transformed >>> >>> widgetDo: aBlock >>> >>> ^ self widget ifNotNil: aBlock >>> >>> into >>> >>> >>> widgetDo: aBlock >>> >>> ^ aBlock cull: self widget >>> >>> BTW I hate all the cull: call. They are connected with sloppiness). It >>> is far too easy to use cull: >>> I do not know how many arguments, I do not care I use cull: >>> cull: is slow slow and help producing messing API. >>> >> > aBlock value: value: value: > > does not much better than cull:, imho. Usually, the api documentation of > the block are just what you'll find in existing code, nothing else. > > >> >>> And it broke. The methodBrowser example did not work anymore and many >>> others. >>> Debugger felt down.... >>> I feel sad. Now my brain is dead so I cannot concentrate more. >>> >>> >>> Stef >>> >>> >> This is a big problem with morphic/spec ui elements. You never know for >> sure >> what code this >> self update ---> search through all (dynamicly added) dependents and >> notify >> will finally call. >> > > I don't think there is any way around it. You have to decouple view(s) > from model(s), and, hence have those propagation constraints by way of > notifications. > > Of course, a true alternative would be to use a proper propagation > constraint system... > > >> In this example we are about to *built* the widgets and in this run , we >> change a component that >> will update all dependents goes back and forth between model, adapter and >> widget. And all >> before the widget is actually accessible for the widgetDo: call. >> >> (and, REALLY we need to clean this up. This is really bad code if we >> announce a textChanged announcement for >> a text component, if we *initialize* an *empty textcomponent* with an >> *empty text*!). >> > > In short, whatever way you look at it, this initialization difficulty is a > hard problem. > > Morphic makes it a bit harder than expected because a Morph can be > considered as active as soon as it is created, not just when it has been > opened in the world. > Here is an example: |t| t:=TextModel new. t text:'hello'. t openWithSpec. t hasUnacceptedEdits it shows that our text has unaccepted edits, although the text did not change. ( and there is actually no text decoration indicating this state). I tried to follow the trace from #openWithSpec to the call that sets #hasUnacceptedEdits:true. I don't think this is a problem of "initialization is difficult" but a problem of pluging rubric text components as widgets for spec. The way spec-models are working and the way rubric works, just don't fit well. (see issue 16873Adding a new Method marks current entry in SendersOf MessageBrowser as dirty for another example. The cause is that rubric somehow changes this "hasUnacceptedEdits state" when the text actually *did not change*. And this again is difficult to trace down. And I don't know how to fix this. Help appreciate > > Thierry > >

Feb. 12, 2016

Re: [Pharo-dev] Getting coherent shortcuts

by Tudor Girba

Thanks. I went over the commits. As I said in the issue, it seems that using a shortcut like arrow + meta + shift does not work on Mac. Any idea why? In the meantime, I reverted the problematic shortcuts from Spotter (for example, dive in category). Cheers, Doru > On Feb 10, 2016, at 3:17 PM, Guille Polito <guillermopolito(a)gmail.com> wrote: > > Cool, thanks! (I thought nobody had read that part of the email because of the flood of answers :)) > > Doru, I made the following commits to the Glamour and GToolkit repositories. I let you manage the integration/merge/configurations. If you have any comments, go on ^^ > > Name: Glamour-Core-GuillermoPolito.312 > Author: GuillermoPolito > Time: 9 February 2016, 3:35:00.429222 pm > UUID: 7b5e7388-3e60-4500-ad80-8fa51e3e55c3 > Ancestors: Glamour-Core-AndreiChis.311 > > Coherent Shortcuts - big pass > > > > Name: GT-Spotter-GuillermoPolito.356 > Author: GuillermoPolito > Time: 10 February 2016, 3:08:08.471892 pm > UUID: 92142dbd-9a1e-461f-a1f8-5716d85be62a > Ancestors: GT-Spotter-AliakseiSyrel.355 > > Coherent Shortcuts - big pass > > > > Name: Glamour-Morphic-Widgets-GuillermoPolito.190 > Author: GuillermoPolito > Time: 9 February 2016, 3:35:06.355081 pm > UUID: 1dd0f9e4-9776-4eb5-b449-ea21e9c1cd24 > Ancestors: Glamour-Morphic-Widgets-AndreiChis.189 > > Coherent Shortcuts - big pass > > > > Name: Glamour-Tests-Morphic-GuillermoPolito.136 > Author: GuillermoPolito > Time: 9 February 2016, 3:35:00.874947 pm > UUID: ba1deabc-2e70-4a7d-bd91-55be918ee0bb > Ancestors: Glamour-Tests-Morphic-EstebanLorenzano.135 > > Coherent Shortcuts - big pass > > > > Name: Glamour-Tests-Rubric-GuillermoPolito.20 > Author: GuillermoPolito > Time: 9 February 2016, 3:35:05.73715 pm > UUID: 6d6e6bcf-8ead-4492-9aef-fa582417b1f9 > Ancestors: Glamour-Tests-Rubric-AndreiChis.19 > > Coherent Shortcuts - big pass > > > > On 02/09/2016 11:32 PM, Tudor Girba wrote: >> Thanks Stephan :). >> >> @Guille: Stephan just added you to the SmalltalkHub repository. >> >> Could you ping me when you commit so that I can review? >> >> Cheers, >> Doru >> >> >>> On Feb 9, 2016, at 11:25 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: >>> >>> On 09/02/16 15:50, Guille Polito wrote: >>>> Also, I did some changes in Glamour and GTSpotter, but I have no >>>> permissions to commit there. How do we do to commit in those packages? >>>> Should I ask for permissions or is there any other process in place? >>> There's a magical process by which you complain in the mailing list and then suddenly are able to commit. >>> >>> Stephan >>> >>> >>> >> -- >> www.tudorgirba.com >> www.feenk.com >> >> "No matter how many recipes we know, we still value a chef." >> >> >> >> >> >> >> >> > -- www.tudorgirba.com www.feenk.com "Problem solving should be focused on describing the problem in a way that makes the solution obvious."

Feb. 12, 2016

Re: [Pharo-dev] Spec Experience in Need for Feedback :)

by Nicolai Hess

2016-02-09 13:46 GMT+01:00 stepharo <stepharo(a)free.fr>: > Hi nicolai > > I agree. I will have a look at the Calipso experience of Alain. > Because may be Calipso + Spec layout format would be much nicer. > Did you look at it? > I could not find anything about Calipso, what is it? > Alain just brainstormed but this is interesting for thinking. > > Stef > > What I hate also is that the > > AbstractApdate>>update: aSymbol > > self changed: aSymbol > > This is a bit terrible because the adpater should not exist at runtime > and adapter should just encapsulate how to create and set the > communication > between the model and the view. Now it is in the middle and this is not > good. > > stef > > > Le 8/2/16 11:31, Nicolai Hess a Ã©crit : > > > > 2016-02-08 10:37 GMT+01:00 stepharo <stepharo(a)free.fr>: > >> Hi guys >> >> I should say that I'm sick (gift from my little boy) so may be this is >> obvious. >> >> I'm looking at the code of Spec and I hate this code :) >> >> widgetDo: aBlock >> >> ^ self widget ifNotNil: aBlock >> >> >> I do not see why widgetDo: has to test for nil >> So I transformed >> >> widgetDo: aBlock >> >> ^ self widget ifNotNil: aBlock >> >> into >> >> >> widgetDo: aBlock >> >> ^ aBlock cull: self widget >> >> BTW I hate all the cull: call. They are connected with sloppiness). It is >> far too easy to use cull: >> I do not know how many arguments, I do not care I use cull: >> cull: is slow slow and help producing messing API. >> >> And it broke. The methodBrowser example did not work anymore and many >> others. >> Debugger felt down.... >> I feel sad. Now my brain is dead so I cannot concentrate more. >> >> >> Stef >> >> > This is a big problem with morphic/spec ui elements. You never know for > sure > what code this > self update ---> search through all (dynamicly added) dependents and notify > will finally call. > In this example we are about to *built* the widgets and in this run , we > change a component that > will update all dependents goes back and forth between model, adapter and > widget. And all > before the widget is actually accessible for the widgetDo: call. > > (and, REALLY we need to clean this up. This is really bad code if we > announce a textChanged announcement for > a text component, if we *initialize* an *empty textcomponent* with an > *empty text*!). > > > >

Feb. 12, 2016

Re: [Pharo-dev] FFI BoxedFloat64 bug?

by ClÃ©ment Bera

I don't understand. All BoxedFloat have 8 bytes, that's why they are called BoxedFloat64. There are no 4-bytes floats in Pharo. Even in 32 bits. 2016-02-12 18:06 GMT+01:00 Esteban Lorenzano <estebanlm(a)gmail.com>: > > On 12 Feb 2016, at 17:50, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > On Fri, Feb 12, 2016 at 5:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> Float>>#pointer >> ^ (ByteArray new: FFIExternalType pointerSize) >> floatAt: 1 put: self; >> yourself >> > > Yes it does the trick :) Thanks! > > > yes and no (I made a mistake): that works because incidentally pointers > and floats have same size (4 bytes)â¦ but can happen that it is not (doubles > have 8 bytes)â¦ but is ok for now :) > I will fix it correctly next week. > > Esteban >

Feb. 12, 2016

Re: [Pharo-dev] [Vm-dev] Termination semaphore for Process

by Eliot Miranda

Hi Max, On Fri, Feb 12, 2016 at 6:59 AM, Max Leske <maxleske(a)gmail.com> wrote: > > Hi all, > > I have a proposal and Iâd like to hear your opinion. > > Right now, when I want to wait for a process to finish I use something > like #forkAndWait or I write a block with semaphores myself. This works > fine for processes that I spawn and then immediately want to wait for. But > what if I spawn a process somewhere else and only later know that I want to > wait for its termination? Currently I would construct a polling loop to do > that. > > Hereâs a different idea (which Iâve tested): > > 1. add instance variable âterminationSemaphoreâ to Process > 2. at the end of Process>>terminate #ensure: that all waiting processes > are signaled > 3. add #waitForTermination message to Process: > > waitForTermination > terminationSemaphore ifNil: [ terminationSemaphore := Semaphore > new ]. > self resume. > terminationSemaphore wait > > > > This enables code like the following: > > result := 0. > p := [ result := 2. 2 seconds asDelay wait ] newProcess > priority: 20; > yourself. > > âdonât run the new process yet" > [ p waitForTermination. result2 := 3. ] forkAt: 30. > âp is now running, the second process is waiting" > > p waitForTermination. > âp is still running, two processes are waitingâ > > âbecause processes waiting on a semaphore are signaled in the order > they sent #wait we even achieve ordering (at least with equal process > priorities) and so âresult2â is not nil but 3â > > {result. result2} â#(2 3) > > > I wrote this in 10 minutes, so thereâs room for polishing. I just want to > know if this is something other people might want and if there are > potential problems with process termination and semaphores which I am not > aware of. > Seems very nice. But why not add both terminationSemaphore and result? So we have Process class methods for instance creation forBlock: aBlockClosure priority: anInteger "Answer an instance of me that has suspended aContext at priority anInteger." <primitive: 19> "Simulation guard" | newProcess | (newProcess := self new) suspendedContext: [newProcess result: aBlockClosure value. newProcess terminationSemaphore ifNotNil: [:ts| ts signal]. "Since control is now at the bottom there is no need to terminate (which runs unwinds) since all unwinds have been run. Simply suspend. Note that we must use this form rather than e.g. Processor suspendActive so that isTerminated answers true. isTerminated requires that if there is a suspended context it is the bottom-most, but using a send would result in the process's suspendedContext /not/ being the bottom-most." newProcess suspend] asContext; priority: anInteger. ^newProcess BlockClosure methods for scheduling newProcess "Answer a Process running the code in the receiver. The process is not scheduled." ^Process forBlock: self priority: Processor activePriority Process methods for termination waitForTermination terminationSemaphore ifNil: [ terminationSemaphore := Semaphore new ]. self resume. terminationSemaphore wait. ^result and hence ((1 to: 3) collect: [:i| [(Delay forSeconds: i) wait. i] forkAt: Processor activePriority - 1]) collect: [:p| p waitForTermination] #(1 2 3) [find attached, leaving BlockClosure>>newProcessWith: as an exercise for the reader ;-) ] _,,,^..^,,,_ best, Eliot

Feb. 12, 2016

Re: [Pharo-dev] FFI BoxedFloat64 bug?

by Esteban Lorenzano

> On 12 Feb 2016, at 17:50, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > On Fri, Feb 12, 2016 at 5:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com <mailto:estebanlm@gmail.com>> wrote: > Float>>#pointer > ^ (ByteArray new: FFIExternalType pointerSize) > floatAt: 1 put: self; > yourself > > Yes it does the trick :) Thanks! yes and no (I made a mistake): that works because incidentally pointers and floats have same size (4 bytes)â¦ but can happen that it is not (doubles have 8 bytes)â¦ but is ok for now :) I will fix it correctly next week. Esteban

Feb. 12, 2016

Re: [Pharo-dev] FFI BoxedFloat64 bug?

by Aliaksei Syrel

> > (and you can commit it to Pharo/NB-FFI repoâ¦ Iâm taking a plane now and I > do not have the time until thursday :( ) done Cheers, Alex On Fri, Feb 12, 2016 at 5:50 PM, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > On Fri, Feb 12, 2016 at 5:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com> > wrote: > >> Float>>#pointer >> ^ (ByteArray new: FFIExternalType pointerSize) >> floatAt: 1 put: self; >> yourself >> > > Yes it does the trick :) Thanks! >

Feb. 12, 2016

Re: [Pharo-dev] FFI BoxedFloat64 bug?

by Aliaksei Syrel

On Fri, Feb 12, 2016 at 5:45 PM, Esteban Lorenzano <estebanlm(a)gmail.com> wrote: > Float>>#pointer > ^ (ByteArray new: FFIExternalType pointerSize) > floatAt: 1 put: self; > yourself > Yes it does the trick :) Thanks!

Feb. 12, 2016

Re: [Pharo-dev] FFI BoxedFloat64 bug?

by Esteban Lorenzano

Oopsâ¦ I didnât implemented #pointer for floatsâ¦ it should be something like this: Float>>#pointer ^ (ByteArray new: FFIExternalType pointerSize) floatAt: 1 put: self; yourself can you test it? (and you can commit it to Pharo/NB-FFI repoâ¦ Iâm taking a plane now and I do not have the time until thursday :( ) Esteban > On 12 Feb 2016, at 16:46, Aliaksei Syrel <alex.syrel(a)gmail.com> wrote: > > We have two identical bloc images built on ci with one day difference and no changes to bloc > https://ci.inria.fr/pharo-contribution/job/Bloc/26/ <https://ci.inria.fr/pharo-contribution/job/Bloc/26/> - works > https://ci.inria.fr/pharo-contribution/job/Bloc/27/ <https://ci.inria.fr/pharo-contribution/job/Bloc/27/> - drawing crashes with the following error: > > <Screen Shot 2016-02-12 at 16.33.51.png> > > Looks like fix to issue https://pharo.fogbugz.com/f/cases/17564 <https://pharo.fogbugz.com/f/cases/17564> in #50579 causes bug. > > Cheers, > Alex >

Feb. 12, 2016

Re: [Pharo-dev] Getting coherent shortcuts

by Guille Polito

I'm not sure I've fixed all shortcuts ever :). Only the ones using keymappings. In any case, the issue that is fixing most of the things is not yet integrated because there are failing tests: https://pharo.fogbugz.com/f/cases/17552/In-Linux-some-shortcuts-use-alt-som… On 02/12/2016 01:55 PM, Damien Cassou wrote: > Guille Polito <guillermopolito(a)gmail.com> writes: > >> I had to touch several packages, which some are not in the Pharo >> repository. For this I prepared several issues for the monkey: > In the TestRunner, on Linux, when I press Ctrl+a to select everything, > nothing is selected. I have to press Alt+a which is not a standard Linux > shortcut for selecting everything. >

Feb. 12, 2016