- Pharo-dev - lists.pharo.org

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

FFI BoxedFloat64 bug?

by Aliaksei Syrel

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/ - works https://ci.inria.fr/pharo-contribution/job/Bloc/27/ - drawing crashes with the following error: [image: Inline image 1] Looks like fix to issue https://pharo.fogbugz.com/f/cases/17564 in #50579 causes bug. Cheers, Alex

Feb. 12, 2016

Termination semaphore for Process

by Max Leske

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. Cheers, Max

Feb. 12, 2016

Re: [Pharo-dev] name of the warning

by Sven Van Caekenberghe

In the same area: I also find it hard to get a hold of the exception object itself. Good exception objects often contain interesting information, but that seems to hard to get to. > On 12 Feb 2016, at 14:21, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi, > > was the name of the warning (signal) intentionally removed from the Debugger's title? > > <warning.png> > â > Now to get the actual error message I have to select the text and print it instead of just reading the title. > > Peter

Feb. 12, 2016