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

Re: [Pharo-dev] About LayoutFrame>>fractions:offsets:

by Tudor Girba

> On Jan 9, 2016, at 9:09 PM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: > > Le 09/01/2016 13:59, stepharo a Ã©crit : >> Hi thierry >>> Stef, >>> >>> could you deprecate the use of fractions:offsets: ? It's a nice way of >>> shooting oneself in the foot. >> Yes we should in fact. >> Today I was thinking that there may be cases where this api makes sense >> but your remark in the bug tracker >> made me think and you are right. >> >>> Create a LayoutFrame taking all space: >>> >>> LayoutFrame fractions: (0@0 corner: 1@1) >>> >>> right? >> better LayoutFrame identity :) > > Well, maybe the comment could say that the 0@0 corner: 1@1 rectangle is the identity ;) > > That this is the identity is not obvious in fact, unless you consider what algorithm is used to compute layouts. I tend to think that this (0@0 corner: 1@1) rectangle is the full area (the max area?)... not the identity of something. > > Why not LayoutFrame fullFrame ? Indeed, this sounds better. Doru > Thierry -- www.tudorgirba.com www.feenk.com "Be rather willing to give than demanding to get."

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Francisco Ortiz PeÃ±aloza

Hi, i would like to have the GTDebugger in the near future. Great job and thanks! I like the Esteban built instead of the original one and i agree with stef on removing _stack and _thisContext from top and the bytecode view. Aim to simplicity must be a top priority and if anybody needs something more specific can change it easily (its moldable!) Cheers Francisco On Sat, Jan 9, 2016 at 12:07 PM, Henrik Nergaard <henrik.nergaard(a)uia.no> wrote: > http://ws.stfx.eu/3KXXDAJ4EUF6 > > > -----Original Message----- > From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of > Stephan Eggermont > Sent: Saturday, January 9, 2016 3:36 PM > To: pharo-dev(a)lists.pharo.org > Subject: Re: [Pharo-dev] gtdebugger in pharo 5.0 > > On 09-01-16 12:39, Dimitris Chloupis wrote: > > there has been around a script to automate the screenshots, but > > personally I never bother using it because taking a screenshot and > > inserting in pillar is the easiest thing. > > AFAIK the hard part is keeping things up to date. That's where automation > helps. > > Stephan > > > >

Jan. 9, 2016

Re: [Pharo-dev] Help with FFI crash in latest Spur (only in Linux)

by Eliot Miranda

Mariano, if you followed the approach I described recently you wouldn't be having these problems. Instead, the system would be generating the information you need to know about sizes for you automatically. Eventually you're going to have to grasp the nettle of how to import platform-specific information such as structure sizes, values of $defines, layout of structs, etc, etc. I presented a straightforward approach but you've yet to comment on it. On Sat, Jan 9, 2016 at 4:54 AM, Mariano Martinez Peck <marianopeck(a)gmail.com > wrote: > Hi Ben, allf > > Ok, I can also confirm that doing ExternalAddress allocate: 76 does work > in Linux. And yes, since it's opaque I don't have to map it and just > allocating the correct size is enough. > I expect this would work in all GNU libc (glibc) based UNIXses. > Esteban, well, I thought the init function would do both, allocate and > init, but in glibc it seems it only init. In OSX it seems it does both. But > from the API point of view it's not explicit that they should allocate the > space. > > Anyway, I think we get this working this time. Thanks all for the help. > > Now the problem I am facing (in Linux) is that my none blocking pipes do > not seem to be none blocking or either feof() call is not working as > expected. Ok, I have to deal with this one now. > > Thanks!! > > > On Sat, Jan 9, 2016 at 9:44 AM, Ben Coman <btc(a)openinworld.com> wrote: > >> On Sat, Jan 9, 2016 at 12:15 PM, Ben Coman <btc(a)openinworld.com> wrote: >> > On Sat, Jan 9, 2016 at 7:12 AM, Mariano Martinez Peck >> > <marianopeck(a)gmail.com> wrote: >> >> >> >> On Jan 8, 2016 4:13 PM, "Ben Coman" <btc(a)openinworld.com> wrote: >> >>> >> >>> On Sat, Jan 9, 2016 at 2:04 AM, Mariano Martinez Peck >> >>> <marianopeck(a)gmail.com> wrote: >> >>> > Hi guys, >> >>> > >> >>> > I wonder if someone could give me a hand to find out why a FFI >> calling I >> >>> > am >> >>> > doing is crashing. In OSX it works correct but I am testing in >> CentOS >> >>> > and it >> >>> > fails. I wonder if it also crashes in other Linuxes too. >> >>> >> >>> I only had enough time to run it a few time so you know it also >> >>> crashes in Debian Jessie 32-bit. There were no debug logs. I got >> >>> these sorts of messages... >> >>> >> >> >> >> Thanks! >> >> >> >>> *** Error in `/home/ben/tst/pharo-vm/pharo': free(): invalid next size >> >>> (fast): 0x08841a70 *** >> >>> >> >>> pharo: malloc.c:3695: _int_malloc: Assertion `(unsigned long) (size) >> >>> >= (unsigned long) (nb)' failed. >> >>> *** Error in `/home/ben/tst/pharo-vm/pharo': malloc(): memory >> >>> corruption: 0x0984c1e0 *** >> >>> >> >>> >> >>> Searching github for "posix_spawn_file_actions_init " >> >>> (https://git.io/vuSPL) >> >>> I see a lot a function definitions of the form... >> >>> int posix_spawn_file_actions_init(posix_spawn_file_actions_t *fa) >> >>> { >> >>> fa->__actions = 0; >> >>> return 0; >> >>> } >> >>> >> >>> ...so it seems you need to first allocate the space for the struct and >> >>> then pass the address of that. >> >> >> >> I thought the same. But I also read in glibc that that the init and >> destroy >> >> would free and alloc exactly so that you don't have to do it. >> >> >> >> In fact, the structure is known to be opaque. I cannot rely in what I >> see in >> >> internet since each os may have a different. >> >> >> >> And I cant get the size of it from ffi so I cannot allocate >> accurately. I >> >> think I am screw. I don't want to go to plugin side grrr .. >> >> >> >> And osx does work. >> >> >> >> I think I will try against glibc rather than libc. >> >> >> >> Another idea? >> >> >> >>> { >> >>> int __allocated; >> >>> int __used; >> >>> struct __spawn_action *__actions; >> >>> int __pad[16]; >> >>> } posix_spawn_file_actions_t; >> >>> // http://linux.die.net/include/spawn.h >> >>> >> >> >> >> But that's opaque right? I cannot rely on that >> > >> > Your ExternalAddress use only allocates 4 bytes for the pointer. You >> > need to also allocate the space for the structure. I guess these may >> > need separate ExternalXXX objects, but just as hack experiment I find >> > below that n:=68 crashes and n:=69 its fine. >> >> Whoops, I missed that the space for the struct seems actually >> allocated by ExternalAddress. Doh! there it is staring at me with the >> #allocate: message. So I guess a separate ExternalXXX object isn't >> required. >> >> > >> > | posixSpawnFileActionsT n | >> > n := 68. "n := 69" >> > posixSpawnFileActionsT := ExternalAddress allocate: n. >> > OSSUnixSubprocess new primitivePosixSpawnFileActionsInit: >> > posixSpawnFileActionsT. >> > posixSpawnFileActionsT free. >> > >> > >> > In trying to understand this I found an interesting article... >> > http://www.catb.org/esr/structure-packing/ >> > What I don't know is for a 32-bit OS on a 64-bit machine, is my >> > pointer 4 or 8 bytes? >> > Assuming 4 I derive the structure size for my 32-bit system is... >> > 4 int __allocated; >> > 4 int __used; >> > 4 struct __spawn_action *__actions; >> > 64 int __pad[16]; >> > 76 posix_spawn_file_actions_t; >> > >> > 76 - 68 = 8 is an interesting round number, but I can't quite reason it >> out. >> >> btw I confirmed *my* structure size by compiling and running... >> #include <stdio.h> >> #include <spawn.h> >> posix_spawn_file_actions_t tst; >> int main() >> { >> printf("-->sizeof=%d\n", sizeof(posix_spawn_file_actions_t)); >> } >> >> -->sizeof=76 >> >> cheers -ben >> >> > With FFI how to you allocate some external memory and then get a >> > pointer to it to pass to primitivePosixSpawnFileActionsInit ? >> > >> > cheers -ben >> > >> >>> > I am using latest Pharo 5.0 with Spur. To reproduce: >> >>> > >> >>> > 1) Get latest Pharo 5.0 and Spur via: >> >>> > wget -O- get.pharo.org/alpha+vm | bash >> >>> > >> >>> > 2) Inside Pharo, load my prototype tool: >> >>> > >> >>> > Gofer it >> >>> > package: 'OSSubprocess'; >> >>> > url: 'http://smalltalkhub.com/mc/marianopeck/OSSubprocess/main'; >> >>> > load. >> >>> > >> >>> > 3) This is the code I am executing and it's crashing: >> >>> > >> >>> > | posixSpawnFileActionsT | posixSpawnFileActionsT := ExternalAddress >> >>> > allocate: 4. OSSUnixSubprocess new >> primitivePosixSpawnFileActionsInit: >> >>> > posixSpawnFileActionsT. posixSpawnFileActionsT free. >> >>> > 4) The primitive is as simple as: >> >>> > >> >>> > primitivePosixSpawnFileActionsInit: aPosixSpawnFileActionsT >> >>> > ^ self ffiCall: #( int posix_spawn_file_actions_init(void* >> >>> > aPosixSpawnFileActionsT) ) module: LibC >> >>> > >> >>> > I have no idea what I am doing wrong. And again, this works on OSX. >> The >> >>> > function I am calling is: int >> >>> > posix_spawn_file_actions_init(posix_spawn_file_actions_t >> *file_actions); >> >>> > as >> >>> > you can read in [1] >> >>> > >> >>> > Below is the stacktrace I get the Linux terminal. >> >>> > >> >>> > Any hint is greatly appreciated. >> >>> > >> >>> > Thanks, >> >>> > >> >>> > >> >>> > [1] >> >>> > >> >>> > >> http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn_file_… >> >>> >> >> > > > -- > Mariano > http://marianopeck.wordpress.com > -- _,,,^..^,,,_ best, Eliot

Jan. 9, 2016

Re: [Pharo-dev] About LayoutFrame>>fractions:offsets:

by Thierry Goubier

Le 09/01/2016 13:59, stepharo a Ã©crit : > Hi thierry >> Stef, >> >> could you deprecate the use of fractions:offsets: ? It's a nice way of >> shooting oneself in the foot. > Yes we should in fact. > Today I was thinking that there may be cases where this api makes sense > but your remark in the bug tracker > made me think and you are right. > >> Create a LayoutFrame taking all space: >> >> LayoutFrame fractions: (0@0 corner: 1@1) >> >> right? > better LayoutFrame identity :) Well, maybe the comment could say that the 0@0 corner: 1@1 rectangle is the identity ;) That this is the identity is not obvious in fact, unless you consider what algorithm is used to compute layouts. I tend to think that this (0@0 corner: 1@1) rectangle is the full area (the max area?)... not the identity of something. Why not LayoutFrame fullFrame ? Thierry

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Ben Coman

On Sat, Jan 9, 2016 at 9:08 PM, stepharo <stepharo(a)free.fr> wrote: > Why do we get bytecodes? > Do you think that normal developpers do not care about bytecodes? > Do you want me to show that to students? Seriously? > I've never used the bytecodes view, but when I see them listed in the inspector on a method I still often think "Wow! You can do that?!" Its cool a hook to let novices peek under the hood and build a sense of mastery. Though I haven't used the GTDebugger for a long time, so I'm not sure whether my sentiment is applicable. cheers -ben > > Stef > > > > > Hi, > > letâs think positive. > the GTDebugger is a step forwardâ¦ it allow a lot of better interactions > and of course, it needs some iterations to make it appealing to everybody. > For instance, I took me 2â to tweak the debugger presentation and to get > this: > > > (I changed all availableâ¦ is a trivial task) > > and like IMO feels a lot betterâ¦ and I think is a good compromise between > the old and the new. > Reasons to suggest this approach: > > - it keeps old approach who(I think) was good (I can see the stack, and > the flow feels natural from top to down) > - it preserves âthe importantâ (the code) as central. > - it gives space for adding columns (like the bytecode). > > Nowâ¦ I can understand you want icons with text, and that can be hacked > tooâ¦ > > Soâ¦ can we have an agreement? > > Esteban > > ps: btwâ¦ using GT with Fast Table we can also avoid those annoying > paginated lists too > > On 09 Jan 2016, at 08:53, stepharo < <stepharo(a)free.fr>stepharo(a)free.fr> > wrote: > > Thanks for your testimony. > > I'm not against GTDebugger per se. I believe that we should have better > tools > but we should take time for building better tools (even if this is two > years that moosers use or not this new debugger). > I would appreciate a process where users can give real feedback and we can > simplify/shape our tools nicely. > > Now for the mooc I will not present GTDebugger. So students will not use > Pharo 50 > > Stef > > Le 08/01/2016 21:22, stepharo a Ã©crit : > > I'm sorry but this debugger should not be the default one. > MONDAY we are filming our mooc and we have to explain the debugger and > personally I do not see the gain: > - It looks a lot more complex to me and I do not want to have to > redo all the screenshots > of our lecture. > - Just that I have to learn the meaning of small icons. > - Why do we need a special pane for the evaluator > - Why there is a type column. > - Sorry but I'm not convinced about the moldable aspect behind the > story (no need to argue I know it) > > I would like to avoid to be forced to use not the latest version of > Pharo for the mooc. > > Such changes are arriving far too late in the release. We do not change > the debugger itself the day of code freeze. > > We decided that the GTDebugger can be included but to me it never meant > that it should be the default one. > I think that experts can choose the debugger they want. The newbies don't. > > Stef > > > IMO the old debugger is way more intuitive. > When I used the debugger of Eclipse for java I was lost. When I used > Spec debugger I thought "Oh, this is not so hard in fact". And I lose > the feeling with GTDebugger. And the debugger is one of the main source > of interest for newbies. > > Maybe we could have a button on the spec Debugger "Switch to GTDebugger"? > > > > > >

Jan. 9, 2016

Re: [Pharo-dev] Help with FFI crash in latest Spur (only in Linux)

by Ben Coman

On Sat, Jan 9, 2016 at 8:54 PM, Mariano Martinez Peck <marianopeck(a)gmail.com> wrote: > Hi Ben, allf > > Ok, I can also confirm that doing ExternalAddress allocate: 76 does work in > Linux. And yes, since it's opaque I don't have to map it and just allocating > the correct size is enough. Its probably not 76 bytes in 64-bit though. Can someone on 64-bit report the result of my little C-code sample. Probably its okay initially to waste a few bytes on 32-bit until we have something to calculate these at runtime (btw, what is the current state/plans for such a feature). > I expect this would work in all GNU libc (glibc) based UNIXses. > Esteban, well, I thought the init function would do both, allocate and init, > but in glibc it seems it only init. In OSX it seems it does both. But from > the API point of view it's not explicit that they should allocate the space. > > Anyway, I think we get this working this time. Thanks all for the help. > > Now the problem I am facing (in Linux) is that my none blocking pipes do not > seem to be none blocking or either feof() call is not working as expected. > Ok, I have to deal with this one now. Do you have any code samples? Sounds like an interesting thing to have a look at. cheers -ben > > Thanks!! > > > On Sat, Jan 9, 2016 at 9:44 AM, Ben Coman <btc(a)openinworld.com> wrote: >> >> On Sat, Jan 9, 2016 at 12:15 PM, Ben Coman <btc(a)openinworld.com> wrote: >> > On Sat, Jan 9, 2016 at 7:12 AM, Mariano Martinez Peck >> > <marianopeck(a)gmail.com> wrote: >> >> >> >> On Jan 8, 2016 4:13 PM, "Ben Coman" <btc(a)openinworld.com> wrote: >> >>> >> >>> On Sat, Jan 9, 2016 at 2:04 AM, Mariano Martinez Peck >> >>> <marianopeck(a)gmail.com> wrote: >> >>> > Hi guys, >> >>> > >> >>> > I wonder if someone could give me a hand to find out why a FFI >> >>> > calling I >> >>> > am >> >>> > doing is crashing. In OSX it works correct but I am testing in >> >>> > CentOS >> >>> > and it >> >>> > fails. I wonder if it also crashes in other Linuxes too. >> >>> >> >>> I only had enough time to run it a few time so you know it also >> >>> crashes in Debian Jessie 32-bit. There were no debug logs. I got >> >>> these sorts of messages... >> >>> >> >> >> >> Thanks! >> >> >> >>> *** Error in `/home/ben/tst/pharo-vm/pharo': free(): invalid next size >> >>> (fast): 0x08841a70 *** >> >>> >> >>> pharo: malloc.c:3695: _int_malloc: Assertion `(unsigned long) (size) >> >>> >= (unsigned long) (nb)' failed. >> >>> *** Error in `/home/ben/tst/pharo-vm/pharo': malloc(): memory >> >>> corruption: 0x0984c1e0 *** >> >>> >> >>> >> >>> Searching github for "posix_spawn_file_actions_init " >> >>> (https://git.io/vuSPL) >> >>> I see a lot a function definitions of the form... >> >>> int posix_spawn_file_actions_init(posix_spawn_file_actions_t *fa) >> >>> { >> >>> fa->__actions = 0; >> >>> return 0; >> >>> } >> >>> >> >>> ...so it seems you need to first allocate the space for the struct and >> >>> then pass the address of that. >> >> >> >> I thought the same. But I also read in glibc that that the init and >> >> destroy >> >> would free and alloc exactly so that you don't have to do it. >> >> >> >> In fact, the structure is known to be opaque. I cannot rely in what I >> >> see in >> >> internet since each os may have a different. >> >> >> >> And I cant get the size of it from ffi so I cannot allocate accurately. >> >> I >> >> think I am screw. I don't want to go to plugin side grrr .. >> >> >> >> And osx does work. >> >> >> >> I think I will try against glibc rather than libc. >> >> >> >> Another idea? >> >> >> >>> { >> >>> int __allocated; >> >>> int __used; >> >>> struct __spawn_action *__actions; >> >>> int __pad[16]; >> >>> } posix_spawn_file_actions_t; >> >>> // http://linux.die.net/include/spawn.h >> >>> >> >> >> >> But that's opaque right? I cannot rely on that >> > >> > Your ExternalAddress use only allocates 4 bytes for the pointer. You >> > need to also allocate the space for the structure. I guess these may >> > need separate ExternalXXX objects, but just as hack experiment I find >> > below that n:=68 crashes and n:=69 its fine. >> >> Whoops, I missed that the space for the struct seems actually >> allocated by ExternalAddress. Doh! there it is staring at me with the >> #allocate: message. So I guess a separate ExternalXXX object isn't >> required. >> >> > >> > | posixSpawnFileActionsT n | >> > n := 68. "n := 69" >> > posixSpawnFileActionsT := ExternalAddress allocate: n. >> > OSSUnixSubprocess new primitivePosixSpawnFileActionsInit: >> > posixSpawnFileActionsT. >> > posixSpawnFileActionsT free. >> > >> > >> > In trying to understand this I found an interesting article... >> > http://www.catb.org/esr/structure-packing/ >> > What I don't know is for a 32-bit OS on a 64-bit machine, is my >> > pointer 4 or 8 bytes? >> > Assuming 4 I derive the structure size for my 32-bit system is... >> > 4 int __allocated; >> > 4 int __used; >> > 4 struct __spawn_action *__actions; >> > 64 int __pad[16]; >> > 76 posix_spawn_file_actions_t; >> > >> > 76 - 68 = 8 is an interesting round number, but I can't quite reason it >> > out. >> >> btw I confirmed *my* structure size by compiling and running... >> #include <stdio.h> >> #include <spawn.h> >> posix_spawn_file_actions_t tst; >> int main() >> { >> printf("-->sizeof=%d\n", sizeof(posix_spawn_file_actions_t)); >> } >> >> -->sizeof=76 >> >> cheers -ben >> >> > With FFI how to you allocate some external memory and then get a >> > pointer to it to pass to primitivePosixSpawnFileActionsInit ? >> > >> > cheers -ben >> > >> >>> > I am using latest Pharo 5.0 with Spur. To reproduce: >> >>> > >> >>> > 1) Get latest Pharo 5.0 and Spur via: >> >>> > wget -O- get.pharo.org/alpha+vm | bash >> >>> > >> >>> > 2) Inside Pharo, load my prototype tool: >> >>> > >> >>> > Gofer it >> >>> > package: 'OSSubprocess'; >> >>> > url: 'http://smalltalkhub.com/mc/marianopeck/OSSubprocess/main'; >> >>> > load. >> >>> > >> >>> > 3) This is the code I am executing and it's crashing: >> >>> > >> >>> > | posixSpawnFileActionsT | posixSpawnFileActionsT := ExternalAddress >> >>> > allocate: 4. OSSUnixSubprocess new >> >>> > primitivePosixSpawnFileActionsInit: >> >>> > posixSpawnFileActionsT. posixSpawnFileActionsT free. >> >>> > 4) The primitive is as simple as: >> >>> > >> >>> > primitivePosixSpawnFileActionsInit: aPosixSpawnFileActionsT >> >>> > ^ self ffiCall: #( int posix_spawn_file_actions_init(void* >> >>> > aPosixSpawnFileActionsT) ) module: LibC >> >>> > >> >>> > I have no idea what I am doing wrong. And again, this works on OSX. >> >>> > The >> >>> > function I am calling is: int >> >>> > posix_spawn_file_actions_init(posix_spawn_file_actions_t >> >>> > *file_actions); >> >>> > as >> >>> > you can read in [1] >> >>> > >> >>> > Below is the stacktrace I get the Linux terminal. >> >>> > >> >>> > Any hint is greatly appreciated. >> >>> > >> >>> > Thanks, >> >>> > >> >>> > >> >>> > [1] >> >>> > >> >>> > >> >>> > http://pubs.opengroup.org/onlinepubs/9699919799/functions/posix_spawn_file_… >> >>> >> > > > > -- > Mariano > http://marianopeck.wordpress.com

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Henrik Nergaard

http://ws.stfx.eu/3KXXDAJ4EUF6 -----Original Message----- From: Pharo-dev [mailto:pharo-dev-bounces@lists.pharo.org] On Behalf Of Stephan Eggermont Sent: Saturday, January 9, 2016 3:36 PM To: pharo-dev(a)lists.pharo.org Subject: Re: [Pharo-dev] gtdebugger in pharo 5.0 On 09-01-16 12:39, Dimitris Chloupis wrote: > there has been around a script to automate the screenshots, but > personally I never bother using it because taking a screenshot and > inserting in pillar is the easiest thing. AFAIK the hard part is keeping things up to date. That's where automation helps. Stephan

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Stephan Eggermont

On 09-01-16 12:39, Dimitris Chloupis wrote: > there has been around a script to automate the screenshots, but > personally I never bother using it because taking a screenshot and > inserting in pillar is the easiest thing. AFAIK the hard part is keeping things up to date. That's where automation helps. Stephan

Jan. 9, 2016

Re: [Pharo-dev] Semaphore and Mutex changes summary

by Denis Kudriashov

2016-01-07 14:05 GMT+01:00 Denis Kudriashov <dionisiydk(a)gmail.com>: > It is also explain why we should deprecate Semaphore>>critical: and use > Mutex>>critical: instead. That's second change. > > So we want to move 4 Semaphore methods to Mutex: > > - critical: mutuallyExcludedBlock > > It will relies on new Semaphore method waitIfInterrupted: which block is > executed when waiting process terminated at point where lock was not > acquired. Slice for this already in inbox. > It was wrong idea. I stop slice for the better solution. I will post about it later

Jan. 9, 2016

Re: [Pharo-dev] ifError: implementation is bad

by Denis Kudriashov

2016-01-08 21:30 GMT+01:00 stepharo <stepharo(a)free.fr>: > Indeed people like to play with better API and sometimes this is not > better. > I prefer on:do: because like that I know that this is about Exception > handling. > But it is too long. ifError: is very intuitive name.

Jan. 9, 2016