- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] OpalCompiler evaluate speed

by Marcus Denker

> On 23 Nov 2017, at 23:37, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > Hi Nicolas. > > Just some comments: > > Another thing you can try is to remove the allocation of Opal's IR. It seems people use the IR only through the IRBuilder, so the API can be kept but it can generate directly bytecode instead of IR then bytecode. Removing those allocations would speed things up. It means merging IRFix / IRTranslator / IRBytecodeGenerator somehow and have the IRBuilder API directly call the new resulting merged class. > > Another thing is that when Opal became the default compiler, I evaluated the speed and saw it was slower, but when loading large projects it seemed loading time was dominated by Monticello / source reading / source loading and the compilation time was overall not that significant (< 20% of time). I don't know if this is still the case with GIT. I have problems currently when editing some large methods (it seems in the IDE the method is compiled at each keystroke...) and when doing OpalCompiler recompileAll (which I do often since I edit bytecode sets) but else the performance of Opal seems to be OK. Evaluate performance may be relevant in some cases but I've never found such cases outside of the IDE in production. > Yes, the IR came over from the existing design of the ClosureCompiler for Squeak that Opal is was based on initiallyâ¦ I liked it at first because I was looking into byte code manipulation back then and for that it was quite nice. But for compiling, it adds a layer that is not really needed. If I would do it again I would not use this IR level in the compiler but instead do something simpler and use the BytecodeBuilder directly. But as Clement notes: it is not that much time when doing compilation if you consider the whole use-case of compiling, so this seemed not that of a problem (e.g. for compiling the image, we were happy with a factor 2, I did not benchmark recently, but I think this is what we reached). For the frontend (compile to AST + name analysis), it is fast enough to do syntax highlighting in the browser with it instead of a specialised parser, so that part is quite ok. One other thing that needs cleanup: the API/ OpalCompiler class. This tries to be compatible with the old API (e.g. failBlock) and got quite hacked to death over timeâ¦ we should clean that up. The complexity of #evaluate is partly due to that, I think. Marcus

Nov. 24, 2017

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

by ClÃ©ment Bera

In the VM primitiveSlotAt: / at:Put: mean access to any field (pointer or non pointer, sorry for the confusion Marcus earlier on) of an object. The primitive in the image can be named fieldAt:/fieldAt:put: if it makes more sense for Pharo. #[0] slotAt: 1 => 0 #(#a) slotAt: 1 => #a 0@2 slotAt: 1 => 0 With Pharo 6 blocks: | t | t := #tmp. {[ t ] slotAt: 3 . [ t ] slotAt: 4} => { 0 "numArgs". #tmp } Right now you can do that with instVarAt: on the contrary to what instVarAt: comment states, and this is wrong. On Fri, Nov 24, 2017 at 10:32 AM, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > On 24 Nov 2017, at 00:21, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > On Fri, Nov 24, 2017 at 12:00 AM, Stephane Ducasse <stepharo.self@gmail. > com> wrote: > >> Did you talk with marcus? >> > > I don't understand the connection between slots and this problem with > primitives. > >> >> > There is no connection, just the same name. > > For Slots aka First Class Instance variables: > > I sometimes think that Slot for the first class instance variables might > not be a good name, but then, > the only alternative would be âinstance variableâ, but that is not that > nice either, as these Slots include > virtual variables (that are computed) or variables that are combine stored > in a hidden base slot (e.g. > used for BooleanSlot or PropertySlot). > > So for now I will keep the Slot termâ¦ > > > Marcus > -- ClÃ©ment BÃ©ra Pharo consortium engineer https://clementbera.wordpress.com/ BÃ¢timent B 40, avenue Halley 59650 Villeneuve d'Ascq

Nov. 24, 2017

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

by Marcus Denker

> On 24 Nov 2017, at 00:21, ClÃ©ment Bera <bera.clement(a)gmail.com> wrote: > > > > On Fri, Nov 24, 2017 at 12:00 AM, Stephane Ducasse <stepharo.self(a)gmail.com <mailto:stepharo.self@gmail.com>> wrote: > Did you talk with marcus? > > I don't understand the connection between slots and this problem with primitives. > There is no connection, just the same name. For Slots aka First Class Instance variables: I sometimes think that Slot for the first class instance variables might not be a good name, but then, the only alternative would be âinstance variableâ, but that is not that nice either, as these Slots include virtual variables (that are computed) or variables that are combine stored in a hidden base slot (e.g. used for BooleanSlot or PropertySlot). So for now I will keep the Slot termâ¦ Marcus

Nov. 24, 2017

Re: [Pharo-dev] OpalCompiler evaluate speed

by Marcus Denker

> On 22 Nov 2017, at 21:14, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > > Thanks this is good. > I think that Opal deserves more energy. > We are busy right now. Now marcus will certainly be interested. Yes, sadly I am over capacity. I can not react (or even read) every email send to the mailinglist anymore. I have marked this to check for later. Marcus

Nov. 24, 2017

Re: [Pharo-dev] OpalCompiler evaluate speed

by Nicolas Cellier

2017-11-23 23:37 GMT+01:00 ClÃ©ment Bera <bera.clement(a)gmail.com>: > Hi Nicolas. > > Just some comments: > > Another thing you can try is to remove the allocation of Opal's IR. It > seems people use the IR only through the IRBuilder, so the API can be kept > but it can generate directly bytecode instead of IR then bytecode. Removing > those allocations would speed things up. It means merging IRFix / > IRTranslator / IRBytecodeGenerator somehow and have the IRBuilder API > directly call the new resulting merged class. > > Yes, I was thinking of this optimization: use IR only when we need advanced tools/instrumentation. Another thing is that when Opal became the default compiler, I evaluated > the speed and saw it was slower, but when loading large projects it seemed > loading time was dominated by Monticello / source reading / source loading > and the compilation time was overall not that significant (< 20% of time). > I don't know if this is still the case with GIT. I have problems currently > when editing some large methods (it seems in the IDE the method is compiled > at each keystroke...) and when doing OpalCompiler recompileAll (which I do > often since I edit bytecode sets) but else the performance of Opal seems to > be OK. Evaluate performance may be relevant in some cases but I've never > found such cases outside of the IDE in production. > > Best ! > > Clement > > Right, my case was generating the strings, so Compiler was the main contributor. For more general case, it should be benched. I was thinking of a tool for checking the example comments "some code example >>> some result". > On Thu, Nov 23, 2017 at 9:41 PM, Nicolas Cellier < > nicolas.cellier.aka.nice(a)gmail.com> wrote: > >> >> >> 2017-11-22 0:31 GMT+01:00 Ben Coman <btc(a)openinworld.com>: >> >>> >>> >>> On 22 November 2017 at 05:49, Nicolas Cellier < >>> nicolas.cellier.aka.nice(a)gmail.com> wrote: >>> >>>> >>>> >>>> 2017-11-21 14:19 GMT+01:00 Nicolas Cellier < >>>> nicolas.cellier.aka.nice(a)gmail.com>: >>>> >>>>> I have an ArbitraryPrecisionFloatTests doing an exhaustive test for >>>>> printing and reevaluating all positve half precision float. >>>>> >>>>> That's about 2^15 or approximately 32k loop which evaluate snippets >>>>> like >>>>> >>>>> (ArbitraryPrecisionFloat readFrom: '1.123' readStream numBits: 10) >>>>> >>>>> The test was naively written with Compiler evaluate: and was using the >>>>> legacy Compiler. >>>>> >>>>> If I rewrite self class compiler evaluate: the test times out. >>>>> Let's see what increase is necessary: >>>>> >>>>> [ ArbitraryPrecisionFloatTest new testPrintAndEvaluate ] >>>>> timeToRun. >>>>> -> 3s with legacy Compiler >>>>> -> 14s with OpalCompiler >>>>> >>>>> It's not unexpected that intermediate representation (IR) reification >>>>> has a cost, but here the 4.5x is a bit too much... >>>>> This test did account for 1/4 of total test duration already (3s out >>>>> of 12s). >>>>> With Opal, the total test duration doubles... (14s out of 23s) >>>>> >>>>> So let's analyze the hot spot with: >>>>> >>>>> MessageTally spyOn: [ ArbitraryPrecisionFloatTest new >>>>> testPrintAndEvaluate ]. >>>>> >>>>> (I didn't use AndreasSystemProfiler becuase outputs seems a bit >>>>> garbbled, no matter since the primitives do not account that much, a >>>>> MessageTally will do the job) >>>>> >>>>> I first see a hot spot which does not seem that necessary: >>>>> >>>>> | |24.6% {3447ms} RBMethodNode(RBProgramNode)>>formattedCode >>>>> >>>>> From the comments I understand that AST-based stuff requires a pattern >>>>> (DoIt) and an explicit return (^), but this expensive formatting seems too >>>>> much for just evaluating. i think that we should change that. >>>>> >>>>> Then comes: >>>>> >>>>> | |20.7% {2902ms} RBMethodNode>>generate: >>>>> >>>>> which is split in two halves, ATS->IR and IR->bytecode >>>>> >>>>> | | |9.3% {1299ms} RBMethodNode>>generateIR >>>>> >>>>> | | | |11.4% {1596ms} IRMethod>>generate: >>>>> >>>>> But then I see this cost a 2nd time which also leave room for progress: >>>>> >>>>> | |10.9% {1529ms} RBMethodNode>>generateIR >>>>> >>>>> | | |12.9% {1814ms} IRMethod>>generate: >>>>> >>>>> The first is in RBMethodNode>>generateWithSource, the second in >>>>> OpalCompiler>>compile >>>>> >>>>> Last comes the parse time (sourceCode -> AST) >>>>> >>>>> | 13.2% {1858ms} OpalCompiler>>parse >>>>> >>>>> Along with semantic analysis >>>>> >>>>> | 6.0% {837ms} OpalCompiler>>doSemanticAnalysis >>>>> >>>>> ----------------------------------- >>>>> >>>>> For comparison, the legacy Compiler decomposes into: >>>>> >>>>> | |61.5% {2223ms} Parser>>parse:class:category:n >>>>> oPattern:context:notifying:ifFail: >>>>> >>>>> which more or less covers parse time + semantic analysis time. >>>>> That means that Opal does a fair work for this stage. >>>>> >>>>> Then, the direct AST->byteCode phase is: >>>>> >>>>> | 16.9% {609ms} MethodNode>>generate >>>>> >>>>> IR costs almost a 5x on this phase, but we know it's the price to pay >>>>> for the additional features that it potentially offers. If only we would do >>>>> it once... >>>>> >>>>> And that's all for the legacy one... >>>>> >>>>> -------------------------------------- >>>>> >>>>> This little exercize shows that a 2x acceleration of OpalCompiler >>>>> evaluate seems achievable: >>>>> - simplify the uselessely expensive formatted code >>>>> - generate bytecodes once, not twice >>>>> >>>>> Then it will be a bit more 2x slower than legacy, which is a better >>>>> trade for yet to come superior features potentially brought by Opal. >>>>> >>>>> It would be interesting to carry same analysis on method compilation >>>>> >>>> >>>> Digging further here is what I find: >>>> >>>> compile sends generate: and answer a CompiledMethod >>>> translate sends compile but throw the CompiledMethod away, and just >>>> answer the AST. >>>> Most senders of translate will also generate: (thus we generate: twice >>>> quite often, loosing a 2x factor in compilation). >>>> >>>> A 2x gain is a huge gain when installing big code bases, especially if >>>> the custom is to throw image away and reconstruct. >>>> No matter if a bot does the job, it does it for twice many watts and at >>>> the end, we're waiting for the bot. >>>> >>>> However, before changing anything, further clarification is required: >>>> translate does one more thing, it catches ReparseAfterSourceEditing and >>>> retry compilation (once). >>>> So my question: are there some cases when generate: will cause >>>> ReparseAfterSourceEditing? >>>> >>> >>> I don't know the full answer about other cases, but I can provide the >>> background why ReparseAfterSourceEditing was added. >>> >>> IIRC, a few years ago with the move to an AST based system, there was a >>> problem with syntax highlighting where >>> the AST referenced its original source which caused highlighting offsets >>> when reference to source modified in the editor. >>> Trying to work backwards from modified source to update all AST elements >>> source-location proved an intractable problem. >>> The workaround I found was to move only in a forward direction >>> regenerating AST from source every keystroke. >>> Performance was acceptable so this became the permanent solution. >>> >>> I don't have access to an image to check, but you should find >>> ReparseAfterSourceEditing raised only in one location near editor #changed: >>> Maybe this should activate only for interactively modified code, and >>> disabled/bypassed for bulk loading code. >>> For testing purposes commenting it out should not harm the system, just >>> produce visual artifacts in syntax highlighting. >>> >>> >>> >>>> That could happen in generation phase if some byte code limit is >>>> exceeded, and an interactive handling corrects code... >>>> I did not see any such condition, but code base is huge... >>>> >>> >>> At worst, the impact should only be a temporary visual artifact. >>> Corrected on the next keystroke. >>> (unless ReparseAfterSourceEditing has been adopted for other than >>> original purpose, but I'd guess not) >>> >>> cheers -ben >>> >>> Hi Ben, >> Thanks for information. >> We must keep ReparseAfterSourceEditing, it does its job. >> >> But it just sounds like we have an inversion: >> >> translate (source code->AST) does call compile (source >> code->AST->bytecode in a CompiledMethod) >> >> I would expect the other way around: if we want to compile, we need to >> translate first. >> If we want to translate, we don't really need to compile, unless there's >> an hidden reason... >> Thus my question: is there an hidden reason? >> > > > > -- > ClÃ©ment BÃ©ra > Pharo consortium engineer > https://clementbera.wordpress.com/ > BÃ¢timent B 40, avenue Halley 59650 > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g>Villeneuve > d > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> > 'Ascq > <https://maps.google.com/?q=40,+avenue+Halley+59650%C2%A0Villeneuve+d'Ascq&entry=gmail&source=g> >

Nov. 24, 2017

Re: [Pharo-dev] Bloc Tutorial Feedback

by Aliaksei Syrel

Hi Sean, That is awesome, thank you! :) - 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. That is the Iceberg issue (https://github.com/pharo-vcs/iceberg/issues/479) Tutorial requires you to load a stable version of Bloc from *pharo6.1* branch. However, iceberg does not do that and instead loads an ancient bloc version from #master branch because you probably have a shared repo of bloc somewhere on your machine. The tutorial's code is up-to date :) Could you try to remove any bloc clones from you computer, take a fresh pharo6.1 image and install Tutorial following the readme? ( https://github.com/pharo-graphics/Tutorials) Cheers, Alex On 24 November 2017 at 08:38, Stephane Ducasse <stepharo.self(a)gmail.com> wrote: > 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.ht > ml > >> > >

Nov. 24, 2017

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

by Ben Coman

On 24 November 2017 at 13:16, Ben Coman <btc(a)openinworld.com> wrote: > > > 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) > Further simplification dealing *only* with strings (see attached sharedLibString.zip) (also attached is clang3.zip as a step along the way) ___microclang.c___ typedef unsigned uintptr_t; const char* myLibraryString = "library_pointer"; const char * lib_getLibraryString() { return myLibraryString; } int lib_testString( const char *aString ) { unsigned test = (uintptr_t)aString & 0x1; printf("\n test=%d, aString-->%d\n", test, (uintptr_t)aString); if (test) { return 0; } else { return 1; } } ___test.c___ #include <stdio.h> int lib_testString( const char *aString ); const char *lib_getLibraryString(); const char *localString = "local_pointer"; void test( int result, char *note ) { if(result == 0) { printf("That failed (%s)\n", note); } else { printf("That worked (%s)\n", note); } } int main() { const char * libraryString = lib_getLibraryString(); test(lib_testString(libraryString), "library string"); test(lib_testString(localString), "local string"); } $ make > report ___report___ rm -f *so *App clang -g -o staticApp test.c microclang.c ./staticApp test=0, aString-->4196150 That worked (library string) test=0, aString-->4196068 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 test=1, aString-->-792512599 That failed (library string) test=0, aString-->4196484 That worked (local string) cheers -ben

Nov. 24, 2017

Re: [Pharo-dev] [PHARO 7.0A] NEXT ENHANCEMENTS

by Esteban Lorenzano

Nov. 24, 2017

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