- Pharo-dev - lists.pharo.org

Re: [Pharo-dev] [Moose-dev] Re: Re: Call for action for Roassal

by Peter UhnÃ¡k

On Mon, Feb 29, 2016 at 9:43 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > Peter, I cannot use your layout (last version of Moose on OS X). Your > layouts uses NBMacShell, which uses NativeBoost. And since it is not > supported anymore, I cannot run the layout. > Hmmâ¦ that's GraphViz requirement (interface with the shell to execute graphviz)â¦ I'll look into that, although without OS X it will be hard to test. Thanks for the report Peter

Feb. 29, 2016

Re: [Pharo-dev] [Moose-dev] Re: Re: Call for action for Roassal

by Alexandre Bergel

Peter, I cannot use your layout (last version of Moose on OS X). Your layouts uses NBMacShell, which uses NativeBoost. And since it is not supported anymore, I cannot run the layout. Alexandre > On Feb 26, 2016, at 3:42 PM, Peter UhnÃ¡k <i.uhnak(a)gmail.com> wrote: > > Hi Anne, > > I've just added a Roassal plugin with the GraphViz-based layout. > > Note that I had to hack it to work with RTMultiLine (it was originally designed for different lines which are currently not part of Roassal), > so it's possible there will be some issues. > > You can load it (if you have latest Roassal installed) via the Roassal plugin menu, > or by executing the following > > Metacello new > baseline: 'GraphVizLayout'; > repository: 'github://peteruhnak/graphviz-layout:master/repository'; > load > > Then look at the class-side examples in RTGraphVizLayout. > > Finally if you use this, you shouldn't move elements within the layout (because graphviz layout hard-codes the pathing)â¦ we could probably change this in the future, but I am not sure how (ideally the layout would have to be recomputed, but that's expensive to do live), > > So to summarize: > * you must have GraphViz installed in your system > * you must use RTMultiLine for lines (because only they support bending) > > Let me know how it goes, > > <graphviz-2.png><graphviz-1.png> > â > â > > Peter > > On Thu, Feb 25, 2016 at 2:02 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > Oh, I missed this one :). So, now I can refactor the code that is still using the RTEdge class side methods :). > > Great! > > Thanks, > Doru > > > > On Feb 25, 2016, at 1:59 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > > > > Oh, but this has been in Roassal for many months (I have implemented since right after ESUG). You need to use #source:connectFrom:toAll: > > > > Here is an example that randomly generate a graph and render it using this facility: > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > nbOfNodes := 40. > > nbOfRandomEdges := 40. > > > > nodes := 1 to: nbOfNodes. > > edges := (1 to: nbOfRandomEdges) > > collect: [ :notUsed | nodes atRandom -> {nodes atRandom . nodes atRandom} ]. > > > > b := RTMondrian new. > > > > b shape circle color: (Color black alpha: 0.5). > > b nodes: nodes. > > > > b shape line color: (Color gray alpha: 0.3). > > b edges > > source: edges connectFrom: #key toAll: #value. > > > > b layout force. > > b > > -=-=-=-=-=-=-=-=-=-=-=-=-=-=-= > > > > <Screen Shot 2016-02-25 at 1.57.24 PM.png> > > > > Cheers, > > Alexandre > > > >> On Feb 25, 2016, at 1:37 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >> > >> Hi, > >> > >> We discussed this before. Try to draw a hierarchy using classes and inheritance objects (so, without using the class to superclass navigation). Something like this: > >> > >> view := RTMondrian new. > >> view nodes: classes. > >> view edges objects: inheritances; connectFrom: #superclass to: #subclass. > >> view layout tree. > >> view > >> > >> It wonât work. > >> > >> Cheers, > >> Doru > >> > >> > >>> On Feb 25, 2016, at 1:29 PM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >>> > >>> Do you have an example? I am not sure to understand. > >>> > >>> Alexandre > >>> > >>> > >>>> On Feb 25, 2016, at 12:40 PM, Tudor Girba <tudor(a)tudorgirba.com> wrote: > >>>> > >>>> This is very cool. We will all benefit from this documentation. > >>>> > >>>> One thing that I would still like to see fixed before the release is the edge building (this problem of not being able to properly specify random objects to be taken into account when building edges). Could we work on that? > >>>> > >>>> Cheers, > >>>> Doru > >>>> > >>>> > >>>>> On Feb 24, 2016, at 9:51 AM, Alexandre Bergel <alexandre.bergel(a)me.com> wrote: > >>>>> > >>>>> Dear community, > >>>>> > >>>>> As you may have seen, Roassal has entered a stabilization phase. The book AgileVisualization.com will soon be released. After its release, Roassal will go over a new development phase. In order to prepare it, I am asking this question: > >>>>> > >>>>> What are the 3 aspects you would like to see improved in Roassal? > >>>>> > >>>>> You can answer publicly or by sending private messages. > >>>>> > >>>>> Kind regards, > >>>>> Alexandre > >>>>> -- > >>>>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>>>> Alexandre Bergel http://www.bergel.eu > >>>>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>>>> > >>>>> > >>>>> > >>>>> _______________________________________________ > >>>>> Moose-dev mailing list > >>>>> Moose-dev(a)list.inf.unibe.ch > >>>>> https://www.list.inf.unibe.ch/listinfo/moose-dev > >>>> > >>>> -- > >>>> www.tudorgirba.com > >>>> www.feenk.com > >>>> > >>>> âLive like you mean it." > >>>> > >>>> > >>> > >>> -- > >>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > >>> Alexandre Bergel http://www.bergel.eu > >>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > >>> > >>> > >>> > >>> _______________________________________________ > >>> Moose-dev mailing list > >>> Moose-dev(a)list.inf.unibe.ch > >>> https://www.list.inf.unibe.ch/listinfo/moose-dev > >> > >> -- > >> www.tudorgirba.com > >> www.feenk.com > >> > >> "Value is always contextual." > >> > >> > >> > >> > >> > > > > -- > > _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: > > Alexandre Bergel http://www.bergel.eu > > ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;. > > > > > > > > _______________________________________________ > > Moose-dev mailing list > > Moose-dev(a)list.inf.unibe.ch > > https://www.list.inf.unibe.ch/listinfo/moose-dev > > -- > www.tudorgirba.com > www.feenk.com > > "Next time you see your life passing by, say 'hi' and get to know her." > > > > > _______________________________________________ > Moose-dev mailing list > Moose-dev(a)list.inf.unibe.ch > https://www.list.inf.unibe.ch/listinfo/moose-dev > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 29, 2016

Re: [Pharo-dev] Run time checking with design by contract assertions

by Alexandre Bergel

Having a solid Design by Contract mechanism is notoriously difficult to have. What you can do, is to have a shallow copy for now. If necessary, you may have a bounded deep copy. But do not use #deepCopy. They are many objects where you cannot do a #deepCopy, because it will copy the whole image, and it does not handle cycles. Cheers, Alexandre > On Feb 29, 2016, at 8:31 AM, Alain Rastoul <alf.mmm.cat(a)gmail.com> wrote: > > On 28/02/2016 20:59, Alexandre Bergel wrote: >> Yes, that is a crucial point. This is a feature that having Object>>assert: aBlock cannot easily emulate > Hi Alexandre > yes it is possible, with the limitation pointed to by Stef: deep copy is a complex thing and I don't measure the implications. > I can't figure out the result of a stack deep copy (ie a thiscontext object), thinking just about this one, they are others. > May be DeepCopier would help ? > > They are other situations leading to unpredictable results. > (Object>>#value) > ast link: ( > MetaLink new > metaObject: true; > control: #after; > arguments: #( ) ; > selector: #value ) . > hangs the vm immediatly -it's like sawing off the branch on which we are sitting. > This situation that can be protected with a simple fencing mechanism (avoiding checking of some classes and/or methods), but more complex cases will show off. > > More investigations are needed here, > but even not perfect, this would still be a valuable tool IMHO > > > -- > > Alain > > -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 29, 2016

Re: [Pharo-dev] Run time checking with design by contract assertions

by Alain Rastoul

On 28/02/2016 20:59, Alexandre Bergel wrote: > Yes, that is a crucial point. This is a feature that having Object>>assert: aBlock cannot easily emulate Hi Alexandre yes it is possible, with the limitation pointed to by Stef: deep copy is a complex thing and I don't measure the implications. I can't figure out the result of a stack deep copy (ie a thiscontext object), thinking just about this one, they are others. May be DeepCopier would help ? They are other situations leading to unpredictable results. (Object>>#value) ast link: ( MetaLink new metaObject: true; control: #after; arguments: #( ) ; selector: #value ) . hangs the vm immediatly -it's like sawing off the branch on which we are sitting. This situation that can be protected with a simple fencing mechanism (avoiding checking of some classes and/or methods), but more complex cases will show off. More investigations are needed here, but even not perfect, this would still be a valuable tool IMHO -- Alain

Feb. 29, 2016

Re: [Pharo-dev] Who is using Pharo Launcher and for what

by Peter Uhnak

I wrote a bash script for such situations https://github.com/peteruhnak/pharo-scripts/blob/master/bin/get-image so I can easily script it from bash. Plus I do such experiments in ramdisk so I don't need to bother will deleting them because it gets autocleaned. -----Original Message----- From: "Stephan Eggermont" <stephan(a)stack.nl> Sent: â2/â28/â2016 12:41 PM To: "pharo-dev(a)lists.pharo.org" <pharo-dev(a)lists.pharo.org> Cc: "pharo-users(a)lists.pharo.org" <pharo-users(a)lists.pharo.org> Subject: Re: [Pharo-dev] Who is using Pharo Launcher and for what On 20-02-16 11:49, Damien Cassou wrote: > I don't need long paragraphs, just give me the keywords please. Today I triaged a bug in CodePanel by downloading image versions 50600 50590 50595 50597 and 50596 and installing NewUI from the catalog browser to find out that it was broken by a change in 50596. With PharoLauncher it took me about 5 minutes, just long enough to wonder if I should automate this further, and just short enough to not bother. Stephan

Feb. 28, 2016

error: cannot find OpenSSL or Libgcrypt when creating the VM on OSX

by Alexandre Bergel

Here is the trace of the build.sh -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= checking for _FILE_OFFSET_BITS value needed for large files... no checking for ld used by GCC... /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld checking if the linker (/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/ld) is GNU ld... no checking for shared library run path origin... done checking for libssl... no checking for libgcrypt... no configure: error: cannot find OpenSSL or Libgcrypt, try --with-libssl-prefix=PATH or --with-libgcrypt-prefix=PATH make[2]: *** [thirdParty/libssh2/src/libssh2-stamp/libssh2-configure] Error 1 make[1]: *** [thirdParty/libssh2/CMakeFiles/libssh2.dir/all] Error 2 make: *** [all] Error 2 ~/Desktop/VM_TMP/pharo-vm/build> brew install OpenSSL Warning: openssl-1.0.2a-1 already installed ~/Desktop/VM_TMP/pharo-vm/build> brew install Libgcrypt ==> Downloading ftp://ftp.gnupg.org/gcrypt/libgcrypt/libgcrypt-1.6.3.tar.bz2 Already downloaded: /Library/Caches/Homebrew/libgcrypt-1.6.3.tar.bz2 ==> ./configure --disable-silent-rules --prefix=/usr/local/Cellar/libgcrypt/1.6. ==> make ==> make check Please report to http://bugs.gnupg.org ====================================== make[2]: *** [check-TESTS] Error 1 make[1]: *** [check-am] Error 2 make: *** [check-recursive] Error 1 READ THIS: https://git.io/brew-troubleshooting ~/Desktop/VM_TMP/pharo-vm/build> -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-= ~/Desktop/VM_TMP/pharo-vm/build> gcc --version Configured with: --prefix=/Applications/Xcode.app/Contents/Developer/usr --with-gxx-include-dir=/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.11.sdk/usr/include/c++/4.2.1 Apple LLVM version 7.0.2 (clang-700.1.81) Target: x86_64-apple-darwin15.2.0 Thread model: posix ~/Desktop/VM_TMP/pharo-vm/build> No idea whatâs going onâ¦ Help :-) Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 28, 2016

Re: [Pharo-dev] Run time checking with design by contract assertions

by Alexandre Bergel

> Now can you support the old value? Yes, that is a crucial point. This is a feature that having Object>>assert: aBlock cannot easily emulate Alexandre -- _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;: Alexandre Bergel http://www.bergel.eu ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.

Feb. 28, 2016

Re: [Pharo-dev] Who is using Pharo Launcher and for what

by Ben Coman

On Sun, Feb 28, 2016 at 7:38 PM, Stephan Eggermont <stephan(a)stack.nl> wrote: > With PharoLauncher it took me about 5 minutes, > just long enough to wonder if I should automate this > further, and just short enough to not bother. Two useful references to consider... https://xkcd.com/1205/ https://xkcd.com/1319/ cheers -ben

Feb. 28, 2016

Re: [Pharo-dev] Spotter changes broke CodePanel

by Stephan Eggermont

In one image I could fix it with Compiler recompileAll The others I tried all ran into the freetype bug. Stephan

Feb. 28, 2016

Re: [Pharo-dev] Spotter changes broke CodePanel

by Stephan Eggermont

GLMBrickExtensionTrait & GLMBrickPropertiesTrait have a lot of duplication. They make GLMBrick flattenDownAllTraits do a MNU as (self traitComposition transformationOfTrait: aTrait) = nil Stephan

Feb. 28, 2016