extending the treemap builder

Hi Doru,

Happy that you played with my ROTreeMapBuilder!

I’d be interested to extend it, but not anytime soon.
At the moment the tree map builder suits my needs and I am focusing on using it on my data ;)

Cheers,
Roby

On Nov 15, 2013, at 6:29 AM, Tudor Girba <[hidden email]> wrote:

> Hi,
>
> I played a bit with the ROTreeMapBuilder, and there are two things that came to mind and that would be nice to extend. I opened some issues:
>
> - Support for multiple types of nodes.
> https://code.google.com/p/moose-technology/issues/detail?id=1002
>
> - Default weight should be 1.
> https://code.google.com/p/moose-technology/issues/detail?id=1003
>
> - Circular treemap
> https://code.google.com/p/moose-technology/issues/detail?id=1004
>
> @Roberto: Would you be interested in working on something like this?
>
> Cheers,
> Doru
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"

> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Well,

We could discuss about it, also with Alex, for example.

One thing which is possible is to subclass the builder and extend it with new features, such that the original code will be consistent with its behavior.

Cheers,
Roby

On Nov 15, 2013, at 7:53 AM, Tudor Girba <[hidden email]> wrote:

> Hi,
>
> Ok. I might give it a try but that will imply that some of the existing code will have a different behavior because it is too restrictive in the way it is now.
>
> Cheers,
> Doru
>
>
> On Fri, Nov 15, 2013 at 7:24 AM, Roberto Minelli <[hidden email]> wrote:
> Hi Doru,
>
> Happy that you played with my ROTreeMapBuilder!
>
> I’d be interested to extend it, but not anytime soon.
> At the moment the tree map builder suits my needs and I am focusing on using it on my data ;)
>
> Cheers,
> Roby
>
> On Nov 15, 2013, at 6:29 AM, Tudor Girba <[hidden email]> wrote:
>
> > Hi,
> >
> > I played a bit with the ROTreeMapBuilder, and there are two things that came to mind and that would be nice to extend. I opened some issues:
> >
> > - Support for multiple types of nodes.
> > https://code.google.com/p/moose-technology/issues/detail?id=1002
> >
> > - Default weight should be 1.
> > https://code.google.com/p/moose-technology/issues/detail?id=1003
> >
> > - Circular treemap
> > https://code.google.com/p/moose-technology/issues/detail?id=1004
> >
> > @Roberto: Would you be interested in working on something like this?
> >
> > Cheers,
> > Doru
> >
> > --
> > www.tudorgirba.com
> >
> > "Every thing has its own flow"
> > _______________________________________________
> > Moose-dev mailing list
> > [hidden email]
> > https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev
>
>
>
> --
> www.tudorgirba.com
>
> "Every thing has its own flow"
> _______________________________________________
> Moose-dev mailing list
> [hidden email]
> https://www.iam.unibe.ch/mailman/listinfo/moose-dev


_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev

I've a fresh installed Moose 4.9 here. If I'm trying ot open
Roassel Eazel I get an Backtrace
NativeBoostLinux32(Object)>>error:
NativeBoostLinux32>>getGlobalSymbolPointer:
NativeBoostLinux32>>loadSymbol:fromModule:
NativeBoost class>>loadSymbol:fromModule:
Metaclass(Object)>>nbGetSymbolAddress:module:
NBFFICallout>>generateCall:module:
NBFFICalloutAPI>>function:module: in Block: [:gen | gen callType: conv;...
NBFFICallout class(NBNativeCodeGen class)>>generateCode:andRetry: in Block: [bytes := aBlock...
BlockClosure>>on:do:
NBRecursionDetect class>>in:during:
NBFFICallout class(NBNativeCodeGen class)>>generateCode:andRetry:
NBFFICallout class(NBNativeCodeGen class)>>handleFailureIn:nativeCode:
NBFFICalloutAPI>>function:module:
AthensCairoSurface class(Object)>>nbCall:
AthensCairoSurface class>>primImage:width:height:
AthensCairoSurface class>>extent:format:
AthensCairoSurface class>>extent:
ROAthensMorph>>extent:
ROAthensMorph(ROMorph)>>setView:
ROAthensMorph class(ROMorph class)>>on:
ROMorphWidgetFactory class>>forView:windowSized:
ROViewStack(ROView)>>openInWindowSized:
ROViewStack(ROView)>>open
ROMondrianViewBuilder>>open
UndefinedObject>>DoIt
Compiler>>evaluate:in:to:notifying:ifFail:logged:
Compiler class>>evaluate:for:notifying:logged:
Compiler class>>evaluate:for:logged:
Compiler class>>evaluate:
ROEaselMorphic>>openViewFor: in Block: [Compiler evaluate: str]


I checked my installation and the symbol is in
/usr/lib/i386-linux-gnu/libcairo.a
 nm libcairo.a | grep cairo_image_surface_create
         U INT_cairo_image_surface_create
         U _cairo_image_surface_create_with_content
         U INT_cairo_image_surface_create
00000b30 T cairo_image_surface_create


Anywy even if I change
pathToCairoOnLinux
        "On different flavors of linux the path to library may differ
        depending on OS distro or whether system is 32 or 64 bit.

        "
        #(

                '/usr/lib/i386-linux-gnu/libcairo.so.2'
                '/usr/lib/libcairo.so.2'

        ) do: [ :path |

                path asFileReference exists ifTrue: [  ^ path ]
        ].

        ^ self cantFindCairoOnLinux

It won't find this "symbol". What is going on?

Regards
Friedrich
_______________________________________________
Moose-dev mailing list
[hidden email]
https://www.iam.unibe.ch/mailman/listinfo/moose-dev