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 roberto.minelli@usi.chwrote:

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 tudor@tudorgirba.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

Subclassing is not really an option. Roassal is a core component that should remain small.

But, let's talk specifics. For example, defining the colorBlock: is a global action. Thus, if I want to define the color for multiple types of nodes I have to use an if in there. This is less ideal.

The alternative would be to use the same pattern that is used in the MondrianBuilder and apply the color to every nodes: instruction. In this way we could handle multiple node types without any ifs.

The same should be valid for every customization in the treemap.

Cheers, Doru

On Fri, Nov 15, 2013 at 8:09 AM, Roberto Minelli roberto.minelli@usi.chwrote:

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 tudor@tudorgirba.com 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 roberto.minelli@usi.ch

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 tudor@tudorgirba.com 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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

-- www.tudorgirba.com

"Every thing has its own flow" _______________________________________________ Moose-dev mailing list Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev

---

Moose-dev mailing list Moose-dev@iam.unibe.ch 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

Hi Friedrich,

In the meantime, before opening the easel, evaluate in a workspace: ROPlatform setCurrent: 'morphic'

It will instead use Morphic

Alexandre

On Nov 19, 2013, at 8:22 AM, Friedrich Dominicus frido@q-software-solutions.de wrote:

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 Moose-dev@iam.unibe.ch https://www.iam.unibe.ch/mailman/listinfo/moose-dev