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

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

by stepharo

Le 9/1/16 11:15, Tudor Girba a Ã©crit : > Hi, > > This issue is still pending: > https://pharo.fogbugz.com/f/cases/7077/LayoutFrame-refactoring > > Let us fix the Glamour issues and then we can deprecate it. Yes please. I should said that I was discouraged when I saw Glamour code but this is easy to fix. There is one spec left and we can be done. I fixed the paginated I do not what. > > Cheers, > Doru > > >> On Jan 9, 2016, at 11:54 AM, Thierry Goubier <thierry.goubier(a)gmail.com> wrote: >> >> Stef, >> >> could you deprecate the use of fractions:offsets: ? It's a nice way of shooting oneself in the foot. >> >> Create a LayoutFrame taking all space: >> >> LayoutFrame fractions: (0@0 corner: 1@1) >> >> right? >> >> Create a layout frame taking all space with an inset of three, so an offset of +3 left and above, and -3 right and bottom: >> >> LayoutFrame fractions: (0@0 corner: 1@1) offsets: (3@3 extent: -3@ -3) >> >> Fail! >> >> See what I mean? You have to forbid the use of a rectangle for offsets! >> >> (Note: I think the easiest API is the one used by Spec and Morphic: Rectangle asLayoutFrame topOffset: / bottomOffset ...) >> >> Thierry >> >> Le 09/01/2016 09:56, stepharo a Ã©crit : >>> Here is the new class comments I'm trying to write. >>> I hope that it will help people to understand the circumstances under >>> which they should use fractions:offset: creation API. >>> >>> >>> >>> I define a transformation frame relative to some rectangle. I'm basic >>> data structure used for graphics. >>> I represent two groups of distances: >>> - The fractional distance (between 0 and 1) to place the morph in its >>> owner's bounds >>> - Fixed pixel offset to apply after fractional positioning (e.g., "10 >>> pixel right of the center of the owner") >>> >>> !! API usage >>> It is important to understand that it is better to use the fine grained >>> API using elementary distances (bottomFraction:, bottomOffset:, >>> leftFraction: ....) than the ones (historical) using points and >>> rectangles (fractions:offsets:) >>> >>> The reason is that the old API (fractions:offsets:) is only interesting >>> if you already have a rectangle and points at hand. If you need to >>> create new ones, then they are created for nothing because they will be >>> destructured to extract their information to be feed into the layoutFrame. >>> So please do not blindly copy and paste code! >>> >>> Example: >>> Favor >>> >>> (LayoutFrame identity >>> leftFraction: 0; >>> yourself); >>> >>> (LayoutFrame identity >>> leftFraction: 0.5; >>> rightFraction: 0.95; >>> >>> (LayoutFrame identity >>> topOffset: topHeight; >>> bottomFraction: 0; >>> bottomOffset: self buttonsBarHeight; >>> leftOffset: -1; >>> rightOffset: 1) >>> over >>> >>> (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) >>> >>> because you are creating for nothing a new rectangle and some points. >>> >>> >>> >>> !! Implementation >>> >>> Instance variables: >>> The fractional distance (between 0 and 1) to place the morph in its >>> owner's bounds is represented by the following instance variables: >>> leftFraction >>> topFraction >>> rightFraction >>> bottomFraction <Float> >>> >>> >>> Fixed pixel offset to apply after fractional positioning (e.g., "10 >>> pixel right of the center of the owner") is represented by the >>> following instance variables: >>> leftOffset >>> topOffset >>> rightOffset >>> bottomOffset <Integer> >>> >>> >> > -- > www.tudorgirba.com > www.feenk.com > > "The coherence of a trip is given by the clearness of the goal." > > > > > > >

Jan. 9, 2016

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

by stepharo

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 :) > > Create a layout frame taking all space with an inset of three, so an > offset of +3 left and above, and -3 right and bottom: > > LayoutFrame fractions: (0@0 corner: 1@1) offsets: (3@3 extent: -3@ -3) > > Fail! > > See what I mean? You have to forbid the use of a rectangle for offsets! oh yes pretty well :) > > (Note: I think the easiest API is the one used by Spec and Morphic: > Rectangle asLayoutFrame topOffset: / bottomOffset ...) > > Thierry > > Le 09/01/2016 09:56, stepharo a Ã©crit : >> Here is the new class comments I'm trying to write. >> I hope that it will help people to understand the circumstances under >> which they should use fractions:offset: creation API. >> >> >> >> I define a transformation frame relative to some rectangle. I'm basic >> data structure used for graphics. >> I represent two groups of distances: >> - The fractional distance (between 0 and 1) to place the morph in its >> owner's bounds >> - Fixed pixel offset to apply after fractional positioning (e.g., "10 >> pixel right of the center of the owner") >> >> !! API usage >> It is important to understand that it is better to use the fine grained >> API using elementary distances (bottomFraction:, bottomOffset:, >> leftFraction: ....) than the ones (historical) using points and >> rectangles (fractions:offsets:) >> >> The reason is that the old API (fractions:offsets:) is only interesting >> if you already have a rectangle and points at hand. If you need to >> create new ones, then they are created for nothing because they will be >> destructured to extract their information to be feed into the >> layoutFrame. >> So please do not blindly copy and paste code! >> >> Example: >> Favor >> >> (LayoutFrame identity >> leftFraction: 0; >> yourself); >> >> (LayoutFrame identity >> leftFraction: 0.5; >> rightFraction: 0.95; >> >> (LayoutFrame identity >> topOffset: topHeight; >> bottomFraction: 0; >> bottomOffset: self buttonsBarHeight; >> leftOffset: -1; >> rightOffset: 1) >> over >> >> (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) >> >> because you are creating for nothing a new rectangle and some points. >> >> >> >> !! Implementation >> >> Instance variables: >> The fractional distance (between 0 and 1) to place the morph in its >> owner's bounds is represented by the following instance variables: >> leftFraction >> topFraction >> rightFraction >> bottomFraction <Float> >> >> >> Fixed pixel offset to apply after fractional positioning (e.g., "10 >> pixel right of the center of the owner") is represented by the >> following instance variables: >> leftOffset >> topOffset >> rightOffset >> bottomOffset <Integer> >> >> > > >

Jan. 9, 2016

Re: [Pharo-dev] need help improving layoutFrame =

by stepharo

thanks stefan. I should have done it with igor some years ago. Le 9/1/16 10:37, Stephan Eggermont a Ã©crit : > On 09-01-16 10:06, stepharo wrote: >> (LayoutFrame fractions: (0 @ 0 corner: 1 @ 1)) = LayoutFrame identity >> should be true and it is not. >> I do not have the time to fix it now. >> >> Stef >> >> > Name: > SLICE-Issue-17363-LayoutFrame-fractions-0--0-corner-1--1--LayoutFrame-identity-should-be-true-and-it-is-not-StephanEggermont.1 > Author: StephanEggermont > Time: 9 January 2016, 10:36:18.036246 am > UUID: 0a7119da-7ed6-4bf2-8581-7c02351dd2de > Ancestors: > Dependencies: Morphic-Base-StephanEggermont.525, > Morphic-Tests-StephanEggermont.7 > > = & hash to avoid comparing with == > > >

Jan. 9, 2016

Re: [Pharo-dev] Why pharo is going over squeaksource when saving code?

by Sven Van Caekenberghe

it is a combination of 2 things: the repo must 1st be defined and used by a package, then there is this odd behaviour of checking all repos for version conflicts. so it depends on what you have loaded. > On 09 Jan 2016, at 12:34, Dimitris Chloupis <kilon.alios(a)gmail.com> wrote: > > eeeehhh that was happening forever at least the last 2 years I am around. How come you guys just noticed ? > > On Sat, Jan 9, 2016 at 1:01 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I saw that too, I choked in my coffee ;-) > > > On 09 Jan 2016, at 10:07, stepharo <stepharo(a)free.fr> wrote: > > > > may be I'm dreaming this morning but when I saved code in the inbox I saw a query to www.squeaksource.com? > > > > Stef > > > >

Jan. 9, 2016

Re: [Pharo-dev] Why pharo is going over squeaksource when saving code?

by stepharo

thanks esteban. I was surprised. Le 9/1/16 10:11, Esteban Lorenzano a Ã©crit : > no, is true :( > the configurations for FFI and Alien are pointing to a place there, and since Monticello isâ¦ wellâ¦ not so goodâ¦ it scans all available repositories to get a version number. > Obviously, not good.. > And I think we changed that last year, but obviously is back. > > in the mean time, I have in my todo to make a mirror for FFI and Alien in sthub and do a configuration who will take packages from there. That will minimise the problem, but it will still be there :( > > Esteban > >> On 09 Jan 2016, at 10:07, stepharo <stepharo(a)free.fr> wrote: >> >> may be I'm dreaming this morning but when I saved code in the inbox I saw a query to www.squeaksource.com? >> >> Stef >> >

Jan. 9, 2016

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

by Mariano Martinez Peck

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

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 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_… >>>

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Dimitris Chloupis

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.On macos is just CMD+SHIFT+4 and you just choose the area you want to screenshot and thats it, it takes a second. Documentation itself is the hard part. Plus I can help with the screenshots , its not big deal. I even have access to the github repo of Mooc but I just try to focus on UPBE. My connection is down at the moment, but when it will be up again, I will be able to help. On Sat, Jan 9, 2016 at 1:33 PM Stephan Eggermont <stephan(a)stack.nl> wrote: > On 08-01-16 21:22, stepharo wrote: > > - It looks a lot more complex to me and I do not want to have to > > redo all the screenshots > > of our lecture. > > What do you need to automate the screenshots? > > Stephan > > >

Jan. 9, 2016

Re: [Pharo-dev] Why pharo is going over squeaksource when saving code?

by Dimitris Chloupis

eeeehhh that was happening forever at least the last 2 years I am around. How come you guys just noticed ? On Sat, Jan 9, 2016 at 1:01 PM Sven Van Caekenberghe <sven(a)stfx.eu> wrote: > I saw that too, I choked in my coffee ;-) > > > On 09 Jan 2016, at 10:07, stepharo <stepharo(a)free.fr> wrote: > > > > may be I'm dreaming this morning but when I saved code in the inbox I > saw a query to www.squeaksource.com? > > > > Stef > > > > >

Jan. 9, 2016

Re: [Pharo-dev] gtdebugger in pharo 5.0

by Stephan Eggermont

On 08-01-16 21:22, stepharo wrote: > - It looks a lot more complex to me and I do not want to have to > redo all the screenshots > of our lecture. What do you need to automate the screenshots? Stephan

Jan. 9, 2016