November 2017 - Pharo-dev - lists.pharo.org

Re: [Pharo-dev] Deploying using the latest minimal image of Pharo (6.1)

by Stephane Ducasse

My idea was even to create objects that generate even bash scripts and all the rest but have objects that we can control and probably to be loaded in another image. I just hate all the undebuggable scripts. On Fri, Nov 24, 2017 at 3:16 AM, Ben Coman <btc(a)openinworld.com> wrote: > > > On 24 November 2017 at 05:13, despotadesdibujau > <despotadesdibujau(a)gmail.com> wrote: >> >> >Hi Gabriel >> >> >This is cool. >> >Thanks for sharing it with us. >> >I really want an object responsible for deploying an app. :) >> >Your effort is nice in that directory. Keep pushing >> >> >Stef >> Thanks!!! >> >> Maxi Tabacman suggests me to reify the deployment process. >> I thought of something like to get up a minimal image from inside the >> development image, then to start the deployment process from the >> development >> image. >> I suppose that I would need to use Espell Object Spaces (Guillermo >> Polito), >> but in this case, I would need a special virtual machine (Oz Virtual >> Machine)... Something like Tornado, but not using the "Run Fail Grow" >> approach, but using a BaselineOf or ConfigurationOf approach. > > > >> >> Another idea (simpler than the idea above) is to communicate the two >> images >> using Teapot or Sockets: The Development image sends orders to the minimal >> image until it becomes on the deployment image. > > > This sounds like a good initiative, but Teapot seems a bit too specific and > Sockets seems a bit too low level. > Consider building on top of TelePharo, or being its sibling by building on > top of Seamless. > These seem better suited to being part of every image than Teapot. > * > http://forum.world.st/Ann-PharmIDE-is-renamed-to-TelePharo-and-moved-to-git… > * > https://dionisiydk.blogspot.com.au/2017/01/pharmide-pharo-remote-ide-to-dev… > * http://forum.world.st/Ann-Major-Seamless-update-td4907335.html > > Others might comment on which is the best level abstraction to use. > > cheers -ben > > >> For the moment I need to test the process (on Pharo 6 and 7) using more >> complex applications until it becomes a reliable process. >> >> Gabriel >> >> >> >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >> >

Nov. 24, 2017

Re: [Pharo-dev] Bloc Tutorial Feedback

by Stephane Ducasse

Aliaksei told me that he should do another pass to add animations and layout chapters. I imagine that he did some refactorings so this is good that you spotted them. On Fri, Nov 24, 2017 at 8:36 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Thanks Sean I will have a look when I get some time. > > > On Fri, Nov 24, 2017 at 4:41 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: >> I did a native English review pass on the first half and submitted a PR on >> GH. >> >> A few other items: >> - When clipping is used to initially draw the card outline as a rounded >> rect, instead of using the rect as a path, it's not immediately obvious why >> this is done. It's only way later when the cross is drawn on the back of the >> card that one /may/ realize that it's so card contents (e.g. the cross) >> don't get drawn outside the rounded bounds. It would be good to explain this >> upfront. >> - The booklet reached from the GH readme seems out of sync with Bloc. I had >> to alter a lot of the animations from the loaded code e.g. >> BlTransformAnimation did not exist (I used BlScaleAnimation instead), >> animations didn't understand #absolute, ` animation startOn: target` needed >> to be changed to `animation target: target; start`, etc. >> >> Otherwise a very nice tutorial. Thanks! >> >> >> >> >> ----- >> Cheers, >> Sean >> -- >> Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >>

Nov. 24, 2017

Re: [Pharo-dev] Bloc Tutorial Feedback

by Stephane Ducasse

Thanks Sean I will have a look when I get some time. On Fri, Nov 24, 2017 at 4:41 AM, Sean P. DeNigris <sean(a)clipperadams.com> wrote: > I did a native English review pass on the first half and submitted a PR on > GH. > > A few other items: > - When clipping is used to initially draw the card outline as a rounded > rect, instead of using the rect as a path, it's not immediately obvious why > this is done. It's only way later when the cross is drawn on the back of the > card that one /may/ realize that it's so card contents (e.g. the cross) > don't get drawn outside the rounded bounds. It would be good to explain this > upfront. > - The booklet reached from the GH readme seems out of sync with Bloc. I had > to alter a lot of the animations from the loaded code e.g. > BlTransformAnimation did not exist (I used BlScaleAnimation instead), > animations didn't understand #absolute, ` animation startOn: target` needed > to be changed to `animation target: target; start`, etc. > > Otherwise a very nice tutorial. Thanks! > > > > > ----- > Cheers, > Sean > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html >

Nov. 24, 2017

Re: [Pharo-dev] [Pharo-users] I love the launcher!!!!

by Stephane Ducasse

Yes I do something similar to ben. Stef On Fri, Nov 24, 2017 at 4:43 AM, Ben Coman <btc(a)openinworld.com> wrote: > Every time I investigate an issue from the tracker, I start with a new fresh > image. > Often its useful to track down which build introduced a bug, so I need to > bisect the last 500 builds or so. > I select a build version from the "Template" side and create an image named > "CaseCCCCC-BBBBB" > where CCCCC is the issue number and BBBBB is the build number. > I'll quickly end up with a dozen images then delete all but the two either > side of where the bug was introduced, > to examine the differences between them, and develop a fix for the later > build, then testing that fix in the latest build. > > Also when someone announces a new library, I can quickly create a new image > "SomeProject-BBBBB" > which I can dip my toes into as I get time available. > > Nowadays the matching VM is automatically downloaded, which makes it easier > to keep up with the latest VM+Image. > > cheers -ben > > On 23 November 2017 at 19:56, Herby VojÄÃk <herby(a)mailbox.sk> wrote: >> >> Stephane Ducasse wrote: >>> >>> Hi >>> >>> I love the PharoLauncher. >> >> >> Pardon my question, I have downloaded it and looked at it, but I don't get >> it. What does it do / what are the use cases (honest question)? >> >> Thanks, Herby >> >> >>> It helps me to manage my parallel development and projects. >>> >>> We should put a link on the Pharo web site because >>> >>> http://files.pharo.org/platform/launcher/ >>> >>> is arcane. >>> >>> Stef >>> >> >> >

Nov. 24, 2017

Re: [Pharo-dev] [Vm-dev] FFI Struct Argument Pass By Value Fails on Mac 64 bit

by Ben Coman

On 22 November 2017 at 21:59, Ben Coman <btc(a)openinworld.com> wrote: > > > On 22 November 2017 at 13:38, Todd Blanchard <tblanchard(a)mac.com> wrote: > >> >> I've been trying to track this down for a couple weeks now. >> >> I have concluded that structs passed by value to functions on the 64 bit >> VM are not properly populated. The struct's memory is all zero'd. >> >> I found this while trying to work with LibClang and found that functions >> that fetched code locations from code ranges always returned invalid zero'd >> locations. After spending some time with lldb I have traced the problem >> into the native code and found that the argument is not correct. >> >> I've carved out the wee bit of clang to reproduce this in a tiny library. >> >> The gist of it is below and the entire file is included. Basically the >> struct passed to the function clang_getRangeStart is zero'd memory >> regardless of the data I send from the image side. >> >> The build command I used on sierra is clang -shared -undefined >> dynamic_lookup -o microclang.dylib microclang.c >> > > On Ubuntu 16.04 I used... > $ clang -shared -fPIC -o libmicroclang.so microclang.c > > $ clang test.c -L. -l microclang > test.c:6:53: error: no member named 'begin_int_data' in > 'CXSourceLocation' > if(clang_getRangeStart(clang_getArbitraryRange()).begin_int_data == 0) > > I presume you meant... > if(clang_getRangeStart(clang_getArbitraryRange()).int_data == 0) > so correcting and continuing... > > $ clang test.c -L. -l microclang > $ LD_LIBRARY_PATH=. ./a.out > That failed > > So I'm not sure how to proceed. > I was expecting that would work while Pharo failed. > > Now interestingly... > $ clang test.c microlang.c > $ ./a.out > That worked > > > So it seems a similar problem exists outside our FFI. > > cheers -ben > > P.S. I refactored you code to extract a header file (attached) > The issue is still beyond my ken, but I've made some progress towards isolating/understanding the issue. Attached zip exploded here for easy reference... ___microlang.h___ typedef unsigned uintptr_t; typedef struct { const void *ptr_data[2]; } CXSourceRange_; CXSourceRange_ clang_getArbitraryRange_(); int clang_getRangeEnd_(CXSourceRange_ range); ___microclang.c___ #include "microclang.h" const char* libraryString = "library_pointer"; CXSourceRange_ clang_getArbitraryRange_() { CXSourceRange_ range = {0}; range.ptr_data[0] = (void*)libraryString; return range; } int clang_getRangeEnd_(CXSourceRange_ range) { // Special decoding for CXSourceLocations for CXLoadedDiagnostics. if ((uintptr_t)range.ptr_data[0] & 0x1) { return 0; } else { return 1; } } ___test.c___ #include <stdio.h> #include "microclang.h" const char* localString = "local_pointer"; void test( CXSourceRange_ range, char *note ) { int result = clang_getRangeEnd_(range); if(result == 0) { printf("That failed (%s)\n", note); } else { printf("That worked (%s)\n", note); } } int main() { CXSourceRange_ range1 = clang_getArbitraryRange_(); test(range1, "library string"); CXSourceRange_ range2 = {0}; range2.ptr_data[0] = (void*)localString; test(range2, "local string"); } ___Makefile___ default: clean static shared clean: rm -f *so *App @echo shared: clang -g -o libmicroclang.so -shared -fPIC microclang.c clang -g -o sharedApp test.c -L. -lmicroclang LD_LIBRARY_PATH=. ./sharedApp @echo static: clang -g -o staticApp test.c microclang.c ./staticApp @echo Now running... $ make > report gives... ___report___ rm -f *so *App clang -g -o staticApp test.c microclang.c ./staticApp That worked (library string) That worked (local string) clang -g -o libmicroclang.so -shared -fPIC microclang.c clang -g -o sharedApp test.c -L. -lmicroclang LD_LIBRARY_PATH=. ./sharedApp That failed (library string) That worked (local string) cheers -ben

Nov. 24, 2017

Re: [Pharo-dev] [Pharo-users] I love the launcher!!!!

by Ben Coman

Every time I investigate an issue from the tracker, I start with a new fresh image. Often its useful to track down which build introduced a bug, so I need to bisect the last 500 builds or so. I select a build version from the "Template" side and create an image named "CaseCCCCC-BBBBB" where CCCCC is the issue number and BBBBB is the build number. I'll quickly end up with a dozen images then delete all but the two either side of where the bug was introduced, to examine the differences between them, and develop a fix for the later build, then testing that fix in the latest build. Also when someone announces a new library, I can quickly create a new image "SomeProject-BBBBB" which I can dip my toes into as I get time available. Nowadays the matching VM is automatically downloaded, which makes it easier to keep up with the latest VM+Image. cheers -ben On 23 November 2017 at 19:56, Herby VojÄÃk <herby(a)mailbox.sk> wrote: > Stephane Ducasse wrote: > >> Hi >> >> I love the PharoLauncher. >> > > Pardon my question, I have downloaded it and looked at it, but I don't get > it. What does it do / what are the use cases (honest question)? > > Thanks, Herby > > > It helps me to manage my parallel development and projects. >> >> We should put a link on the Pharo web site because >> >> http://files.pharo.org/platform/launcher/ >> >> is arcane. >> >> Stef >> >> > >

Nov. 24, 2017

Bloc Tutorial Feedback

by Sean P. DeNigris

I did a native English review pass on the first half and submitted a PR on GH. A few other items: - When clipping is used to initially draw the card outline as a rounded rect, instead of using the rect as a path, it's not immediately obvious why this is done. It's only way later when the cross is drawn on the back of the card that one /may/ realize that it's so card contents (e.g. the cross) don't get drawn outside the rounded bounds. It would be good to explain this upfront. - The booklet reached from the GH readme seems out of sync with Bloc. I had to alter a lot of the animations from the loaded code e.g. BlTransformAnimation did not exist (I used BlScaleAnimation instead), animations didn't understand #absolute, ` animation startOn: target` needed to be changed to `animation target: target; start`, etc. Otherwise a very nice tutorial. Thanks! ----- Cheers, Sean -- Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html

Nov. 24, 2017

Re: [Pharo-dev] Deploying using the latest minimal image of Pharo (6.1)

by Ben Coman

On 24 November 2017 at 05:13, despotadesdibujau <despotadesdibujau(a)gmail.com > wrote: > >Hi Gabriel > > >This is cool. > >Thanks for sharing it with us. > >I really want an object responsible for deploying an app. :) > >Your effort is nice in that directory. Keep pushing > > >Stef > Thanks!!! > > Maxi Tabacman suggests me to reify the deployment process. > I thought of something like to get up a minimal image from inside the > development image, then to start the deployment process from the > development > image. > I suppose that I would need to use Espell Object Spaces (Guillermo Polito), > but in this case, I would need a special virtual machine (Oz Virtual > Machine)... Something like Tornado, but not using the "Run Fail Grow" > approach, but using a BaselineOf or ConfigurationOf approach. > > Another idea (simpler than the idea above) is to communicate the two images > using Teapot or Sockets: The Development image sends orders to the minimal > image until it becomes on the deployment image. > This sounds like a good initiative, but Teapot seems a bit too specific and Sockets seems a bit too low level. Consider building on top of TelePharo, or being its sibling by building on top of Seamless. These seem better suited to being part of every image than Teapot. * http://forum.world.st/Ann-PharmIDE-is-renamed-to-TelePharo-and-moved-to-git… * https://dionisiydk.blogspot.com.au/2017/01/pharmide-pharo-remote-ide-to-dev… * http://forum.world.st/Ann-Major-Seamless-update-td4907335.html Others might comment on which is the best level abstraction to use. cheers -ben For the moment I need to test the process (on Pharo 6 and 7) using more > complex applications until it becomes a reliable process. > > Gabriel > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Developers-f1294837.html > >

Nov. 24, 2017

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

by ClÃ©ment Bera

On Fri, Nov 24, 2017 at 12:00 AM, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > Did you talk with marcus? > I don't understand the connection between slots and this problem with primitives. > > > On Wed, Nov 22, 2017 at 10:12 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> > wrote: > > > > > > On Wed, Nov 22, 2017 at 9:05 PM, Stephane Ducasse < > stepharo.self(a)gmail.com> > > wrote: > >> > >> Hi clement > >> > >> you should discuss with marcus. I had the impression that he was > >> thinking that slot should disappear. > > > > > > Then let's use fieldAt:/fieldAt:put: > > > >> > >> > >> Stef > >> > >> On Wed, Nov 22, 2017 at 2:35 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> > >> wrote: > >> > Hi All, > >> > > >> > It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that > >> > the > >> > instVarAt: / instVarAt:put: primitive is not doing what it says it > does. > >> > When I look at Object>>#instVarAt: I see: > >> > > >> > "[...]Answer a fixed variable in an object. The numbering of the > >> > variables > >> > corresponds to the named instance variables, followed by the indexed > >> > instance > >> > variables. Fail if the index is not an Integer or is not the index of > a > >> > fixed variable[...]" > >> > > >> > Now in Pharo 7 when one does: > >> > > >> > #(iv1) instVarAt: 1, one gets #iv1. > >> > > >> > So the comment is wrong. > >> > > >> > The reason for this is that instVarAt: / instVarAt:put: should be > >> > primitive > >> > 73/74, while they are in Pharo 173/174 (primitive > slotAt:/slotAt:put:). > >> > The > >> > slot primitive access pointer slots of objects, whichever inst var or > >> > variable fields. A good example would be: > >> > > >> > | t | > >> > t := #temp. > >> > [ t ] instVarAt: 4, one gets #temp > >> > > >> > So I have two solutions for this problem: > >> > 1) We change the instVarAt: / instVarAt:put: primitives comments to > >> > match > >> > the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: / > >> > instVarAt:put: > >> > means in factslotAt: / slotAt:put: . > >> > 2) We change the instVarAt: / instVarAt:put: primitives to primitive > 73 > >> > and > >> > 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we > ask > >> > everyone to fix their code relying on instVarAt: / instVarAt:put: > acting > >> > as > >> > slotAt: / slotAt:put: > >> > > >> > What do you think ? > >> > > >> > Best, > >> > > >> > > >> > -- > >> > ClÃ©ment BÃ©ra > >> > Pharo consortium engineer > >> > https://clementbera.wordpress.com/ > >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > >> > > > > > > > > -- > > ClÃ©ment BÃ©ra > > Pharo consortium engineer > > https://clementbera.wordpress.com/ > > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq > > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Nov. 23, 2017

Re: [Pharo-dev] Problem with primitive instVarAt: / instVarAt:put:, what should we do ?

by Stephane Ducasse

Did you talk with marcus? On Wed, Nov 22, 2017 at 10:12 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > On Wed, Nov 22, 2017 at 9:05 PM, Stephane Ducasse <stepharo.self(a)gmail.com> > wrote: >> >> Hi clement >> >> you should discuss with marcus. I had the impression that he was >> thinking that slot should disappear. > > > Then let's use fieldAt:/fieldAt:put: > >> >> >> Stef >> >> On Wed, Nov 22, 2017 at 2:35 PM, ClÃ©ment Bera <bera.clement(a)gmail.com> >> wrote: >> > Hi All, >> > >> > It seems Pharo is lacking the slotAt: / slotAt:put: primitive and that >> > the >> > instVarAt: / instVarAt:put: primitive is not doing what it says it does. >> > When I look at Object>>#instVarAt: I see: >> > >> > "[...]Answer a fixed variable in an object. The numbering of the >> > variables >> > corresponds to the named instance variables, followed by the indexed >> > instance >> > variables. Fail if the index is not an Integer or is not the index of a >> > fixed variable[...]" >> > >> > Now in Pharo 7 when one does: >> > >> > #(iv1) instVarAt: 1, one gets #iv1. >> > >> > So the comment is wrong. >> > >> > The reason for this is that instVarAt: / instVarAt:put: should be >> > primitive >> > 73/74, while they are in Pharo 173/174 (primitive slotAt:/slotAt:put:). >> > The >> > slot primitive access pointer slots of objects, whichever inst var or >> > variable fields. A good example would be: >> > >> > | t | >> > t := #temp. >> > [ t ] instVarAt: 4, one gets #temp >> > >> > So I have two solutions for this problem: >> > 1) We change the instVarAt: / instVarAt:put: primitives comments to >> > match >> > the slotAt: / slotAt:put: behavior, and in Pharo instVarAt: / >> > instVarAt:put: >> > means in factslotAt: / slotAt:put: . >> > 2) We change the instVarAt: / instVarAt:put: primitives to primitive 73 >> > and >> > 74, we introduce slotAt: / slotAt:put: with primitive 173/174 and we ask >> > everyone to fix their code relying on instVarAt: / instVarAt:put: acting >> > as >> > slotAt: / slotAt:put: >> > >> > What do you think ? >> > >> > Best, >> > >> > >> > -- >> > ClÃ©ment BÃ©ra >> > Pharo consortium engineer >> > https://clementbera.wordpress.com/ >> > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq >> > > > > -- > ClÃ©ment BÃ©ra > Pharo consortium engineer > https://clementbera.wordpress.com/ > BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Nov. 23, 2017