Re: [Pharo-users] MooseTechnology failing again. Any way to download Moose Book?

[Tudor Girba]

Hi,

The site is up again. There seemed to be some problems with the provider.
Hopefully, they are fixed now.

As for The Moose Book, at the moment, it is not available in another
format. I am working on porting it to Pillar, and I hope to get some news
on it soon.

Cheers,
Doru



On Sat, Aug 2, 2014 at 9:31 PM, Offray Vladimir Luna Cárdenas <
off...@riseup.net> wrote:

> Hi,
>
> These days, MooseTechnology.org has being failing continuously and I can
> not read any documentation on Moose browsers, except for the one in PBE2.
> There is any way to download this book to see it off-line, hopefully in pdf
> format?
>
> Thanks,
>
> Offray
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] Data Science with Pharo?

[Tudor Girba]

Talking about the vision of Moose: The stated goal of Moose is to enable an
engineer to craft a data analysis in under 15 minutes, whatever the
analysis: metric, query, clustering, visualization, browsing etc.

The goal of Moose is to enable an engineer to craft a data analysis in
under 15 minutes ... whatever the analysis: metric, query, clustering,
visualization, browsing etc.

On the one hand, this will change software development. For example, you
should not manually search for code or objects. Instead, you should build
tools that do it for you. The core idea around the Glamorous Toolkit is to
offer a moldable development environment that allows you to do just that.
This is not a regular toolkit, but it one that embodies a new philosophy
for software development.

On the other hand, we want to build pieces that are generic enough so that
they can be instantiated for any domain while still being accessible. For
example, we think that one should not require a PhD to write a
visualization or to build an interactive browser, and we showed how this is
possible :). This is why it is so easy and inexpensive to build a
completely novel kind of inspector that capture the imagination quite
rapidly. And at this point, people did not even pay much of an attention to
the moldable debugger :).

It's true that we are not where R is in terms of number crunching analyses,
but we have other things around interaction and analysis composition that
are quite unique. We would indeed benefit from more R-like capabilities,
but at this point Moose does no longer play a catch-up game. It is forging
its own separate place that others start to look at. And this is possible
precisely because Moose is almost indistinguishable from Pharo.

I do believe we are sitting on a goldmine, and that it is up to us to
exploit it.

Doru


On Sat, Aug 2, 2014 at 12:20 AM, volk...@nivoba.de 
wrote:

>
> Am 01.08.2014 um 17:38 schrieb Thierry Goubier:
>
>  Le 31/07/2014 15:29, Alexandre Bergel a écrit :
>>
>>> I am successful using Pharo + Roassal/Mondrian in analyzing and
 visualizing IT architecture models. And it is real fun. :-)

>>> Glad to ear this :-)
>>>
>>> Yes, the vision I see behind Pharo, Moose, Roassal is to provide a solid
>>> alternative to R. We are not there yet, but we will get there.
>>>
>> Cool. I'm interested by that objective :)
>>
>> Thierry
>>
>>  Me too
>
> BW,
> Volkert
>
>
>


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] Roassal2 RTDraggable grid and synchronized movement

[Tudor Girba]

I really love this discussion :)

Doru


On Fri, Aug 1, 2014 at 11:36 PM, Alexandre Bergel 
wrote:

> This is an excellent start.
>
> Do you need the grid? If yes, then I can add this to Roassal. It is easy
> to define an interaction that define a grid.
>
> I have added event to signal the beginning and ending of a
> dragging-and-dropping.
> Here is an example:
> -=-=-=-=-=-=-=-=
> | v e |
> v := RTView new.
> e := (RTEllipse new size: 30) element.
> e @ RTDraggable.
> v add: e.
> e when: TRMouseDragStart do: [ :evt | Transcript show: evt printString;
> cr. evt element trachelShape color: Color red. v signalUpdate ].
> e when: TRMouseDragEnd do: [ :evt | Transcript show: evt printString; cr ].
> v  open
> -=-=-=-=-=-=-=-=
>
> Let me know whether this helps.
>
> Cheers,
> Alexandre
> --
> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
> Alexandre Bergel  http://www.bergel.eu
> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>
>
>
> On Aug 1, 2014, at 2:36 PM, Peter Uhnák  wrote:
>
> Hi Alex,
>
> While the "snap to grid" might be complicated I thought of simpler
> solution that might be achievable purely at Roassal level without the need
> to change Trachel classes. You can look at Umlet, since I am trying to copy
> it's grid behavior here.
> Basically you don't move objects with mouse immediately but only after
> fixed increments. However I've encountered a problem with
> TRMouseDragging>>step, since I would probably need to continuously sum the
> individual steps and then reset them when dragging has started.
>
> Here is a _very_ crude prototype:
> -
> "i subclassed RTDraggable and changed initializeElement: method as follows"
> initializeElement: element
>  | sum gridSize |
> gridSize := 20.
> sum := 0 @ 0.
>  element
> when: TRMouseDragging
> do: [ :e |
> | d t |
>  t := RTGroup withAll: groupToDrag.
> (t includes: element)
> ifFalse: [ t add: element ].
>  d := element view canvas camera distanceFromPixelToSpace: e step.
> sum := sum + d.
> "move element only in increments of gridSize"
>  d := gridSize * ((sum x / gridSize) truncated @ (sum y / gridSize)
> truncated).
> sum := sum - d.
> t translateBy: d.
>  e signalUpdate ]
> -
>
> and here is a demo utilizing it
>
> -
> | v e1 e2 line gridSize  b1 b2 b3 b4 edge |
> v := RTView new.
>
> "draw grid"
> gridSize := 20.
>
> (-20 to: 20) do: [ :i |
> b1 := RTBox element.
>  b2 := RTBox element.
> b3 := RTBox element.
> b4 := RTBox element.
>  b1 translateTo: (i * gridSize) @ -1000. "top side"
> b2 translateTo: (i * gridSize) @ 1000. "bottom side"
>  b3 translateTo: -1000 @ (i * gridSize). "left side"
> b4 translateTo: 1000 @ (i * gridSize). "right side"
>  "vertical line"
> edge := RTLine edgeFrom: b1 to: b2.
> v add: edge.
>  "horizontal line"
> edge := RTLine edgeFrom: b3 to: b4.
> v add: edge.
> ].
>
> e1 := (RTEllipse new size: 30; color: Color magenta) element.
> e1 translateTo: -20 @ 0.
> e1 @ RGGridDraggable.
>
> e2 := (RTEllipse new size: 30; color: Color magenta) element.
> e2 translateTo: 20 @ 0.
> e2 @ RGGridDraggable.
>
> (line := RTLine edgeFrom: e1 to: e2) shape color:Color black.
>
> v add: e1; add: e2; add: line.
>
> v open.
> -
>
> Obviously it needs a lot of fine-tuning and such. Since RTInteraction
> (RTDraggable) instances are not created directly the gridSize would have to
> be stored probably class side. Also there is a problem with resetting the
> "sum" variable when dragging starts. (There is no TRMouseDragStart event as
> far as I've seen). And also drawing the grid itself the way I've done is
> very brutal and doesn't really work if I want to move the canvas camera
> (perhaps image pattern as a background would work better).
>
> What are your thoughts on this?
>
> Peter
>
>
>
>
> On Fri, Aug 1, 2014 at 4:07 PM, Alexandre Bergel 
> wrote:
>
>> Hi Peter!
>>
>> > While playing with RTMultiLine I thought that it would be nice to have
>> option for RTDraggable elements to snap to a grid / move only by fixed
>> increments - for example the position could only be divisible by 10 (grid
>> size would be 10), so dragging from 20@10 to 26@4 would jump to 30@0. Is
>> something like this possible with current implementation?
>>
>>
>> I first thought this would be easy. But actually it is not.
>> The way to achieve the snap on grid behavior is to have an indirection in
>> the Trachel classes. Each trachel shape knows its position (the position is
>> contained in the matrix attached to each shape). The snap-on-grid means you
>> need to slightly process the matrix coordinate. Maybe there are other way
>> to do this, but it does not look like. Changing Trachel because of this
>> seems a bit overkill...
>>
>> Cheers,
>> Alexandre
>> --
>> _,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:
>> Alexandre Bergel  http://www.bergel.eu
>> ^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;._,.;:~^~:;.
>>
>>
>>
>> On Jul 31, 2014, at 3:58 PM, Peter Uhnák  wrote:
>>
>> > W

Re: [Pharo-users] MooseTechnology failing again. Any way to download Moose Book?

[stepharo]

doru

since this is a pier we were planning with damien to hack a visitor for 
the seaside book to get the book in pillar.

So may be we can join forces. But damien is back mid august.

Stef

On 3/8/14 13:02, Tudor Girba wrote:

Hi,

The site is up again. There seemed to be some problems with the 
provider. Hopefully, they are fixed now.


As for The Moose Book, at the moment, it is not available in another 
format. I am working on porting it to Pillar, and I hope to get some 
news on it soon.


Cheers,
Doru



On Sat, Aug 2, 2014 at 9:31 PM, Offray Vladimir Luna Cárdenas 
mailto:off...@riseup.net>> wrote:


Hi,

These days, MooseTechnology.org has being failing continuously and
I can not read any documentation on Moose browsers, except for the
one in PBE2. There is any way to download this book to see it
off-line, hopefully in pdf format?

Thanks,

Offray




--
www.tudorgirba.com 

"Every thing has its own flow"

Re: [Pharo-users] Syncing local cache and SmalltalkHub

[Ben Coman]

Offray Vladimir Luna Cárdenas wrote:

Hi,

I have my outliner buggy mockup on local cache, and I would like to 
share the code and point to it online using SmalltalkHub for my 
questions. I have followed the chapter on Source code management with 
Monticello y PBE2, and it says that you can have your code on 
SmalltalkHub, but says nothing about how to sync from local cache to 
your SmalltalkHub account. Can some one could point me the way to do it?


Cheers,

Offray




There is no sync function, but if you open your local repository you can 
use the 'Copy' button to push to SmalltalkHub.  Note that while the 
usual 'Save' button will prompt for your credentials if you haven't 
configured them, 'Copy' will not prompt and you need to have configured 
them, via 'Edit' from the context menu of the repository.

cheers -ben

Re: [Pharo-users] Syncing local cache and SmalltalkHub

[Offray Vladimir Luna Cárdenas]

Juan, Ben and Stef,

Thanks. I tested first Ben's suggestion but Juan's seems to work better 
(first one gave me an error... don't remember well which one). Now I 
have my repo online:


http://smalltalkhub.com/#!/~Offray/Ubakye

When I try to browse the source, I can find .mcz files, but I wonder if 
there is a way to point to a specific method of an specific version and 
see it online.


Cheers,

Offray

On 08/02/2014 05:10 PM, Juan Ignacio Vaccarezza wrote:

Hi Offray,

I recently faced the same problem, the way I solved it by using Gofer to 
sync
the repos.

go := Gofer new.

go repository: (MCSmalltalkhubRepository
  owner: 'You'
  project: 'yourProjectName'
  user: 'userName'
  password: 'yourSecretPass').

go package: 'PackageName'; push.


I got the example from here:
http://pharobooks.gforge.inria.fr/PharoByExampleTwo-Eng/latest/Gofer.pdf

Hope it helps.

Regards,
Juan



On Sat, Aug 2, 2014 at 5:02 PM, Sven Van Caekenberghe mailto:s...@stfx.eu>> wrote:

 Hi Offray,

 Once you create your StHub repository and define it in your image, you can
 just copy versions (mcz files) from your package cache to the new 
repository
 using the Copy button in the Repository browser (which you get by selecting
 your local package cache in the Monticello browser and clicking the Open
 button).

 HTH,

 Sven

 On 02 Aug 2014, at 21:25, Offray Vladimir Luna Cárdenas mailto:off...@riseup.net>> wrote:

  > Hi,
  >
  > I have my outliner buggy mockup on local cache, and I would like to 
share
 the code and point to it online using SmalltalkHub for my questions. I have
 followed the chapter on Source code management with Monticello y PBE2, and
 it says that you can have your code on SmalltalkHub, but says nothing about
 how to sync from local cache to your SmalltalkHub account. Can some one
 could point me the way to do it?
  >
  > Cheers,
  >
  > Offray
  >

[Pharo-users] rethinking compilation notifications

[Tudor Girba]

Hi,

The next stop in our little tour around code actions was the compilation
notifications. Again, we used a popper interface to show the error without
affecting the underlying text editor:

[image: Inline image 2]

You can find more details here:
http://www.humane-assessment.com/blog/rethinking-compilation-notifications-in-pharo/

Please let us know what you think.

Cheers,
Doru


-- 
www.tudorgirba.com

"Every thing has its own flow"

Re: [Pharo-users] rethinking compilation notifications

[Sean P. DeNigris]

Tudor Girba-2 wrote
> compilation notifications... we used a popper interface to show the error
> without
> affecting the underlying text editor:

Thank god! At least it used to be highlighted so you could delete it easily,
but now we don't even have that. Any chance this could be ported easily to
Pharo core?



-
Cheers,
Sean
--
View this message in context: 
http://forum.world.st/rethinking-compilation-notifications-tp4771635p4771640.html
Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.

Re: [Pharo-users] rethinking compilation notifications

[Sven Van Caekenberghe]

On 04 Aug 2014, at 00:07, Sean P. DeNigris  wrote:

> Tudor Girba-2 wrote
>> compilation notifications... we used a popper interface to show the error
>> without
>> affecting the underlying text editor:
> 
> Thank god! At least it used to be highlighted so you could delete it easily,
> but now we don't even have that. Any chance this could be ported easily to
> Pharo core?

+1 Please

> 
> -
> Cheers,
> Sean
> --
> View this message in context: 
> http://forum.world.st/rethinking-compilation-notifications-tp4771635p4771640.html
> Sent from the Pharo Smalltalk Users mailing list archive at Nabble.com.
>